We Keep Coding

Why can't React Native (RN) convert the main.bundle.js to native code to avoid the RN Bridge between VM & Native Modules

I was wondering why do we need the RN Bridge in the React Native engine which connects the Javascript VM (JavascriptCore) with the Native Modules. This bridge and message passing setup only slows down the app speed and creates a bottleneck. Why can't the package bundler spawned by React Native CLI, instead of just bundling javascript codes to main.bundle.js, also convert it to native code? one reason I've heard is coz javascript is not strongly typed, but this reason doesn't seem unsolvable. Any other reasons?

Indeed transpiling javascript into native code will provide tremendous performance improvements however it is not an easy thing to do at all. That being said, there are a lot of reasons why transpilation from one language to another is hard, and this is especially true if we consider the host language to be javascript and the target language to be java or something similar like C# and objective c.
Javascript is extremely different from these languages, many of the ideas are hard to map into a one to one, and the mindset is completely different.
Another thing that is special about javascript, and that makes it hard to transpile it to another language, is that javascript can never be a versioned language, and that since its the language of the web it has to always support backward compatibility. This means if a tool were to transpile from javascript to another language, this tool needs to support everything that javascript supports - one might argue that a tool might support only a recent subset of javascript, something like es6, however this is dangerous for two reasons, one it will be hard to define this subset exactly since a lot of es6 features are working by polyfills from es5, and two that this means that this tool wont be able to support all the javascript ecosystem.
here are some of details about some challenging parts of javascript to be transpiled into a language like java:
javascript is a dynamic language, not only there are no restrictions on types, but javascript do an extremely complex type coercing techniques in different operations under different conditions
consider this
true + 1 === 1 + '1' // false
true + 1 === 1 + +1 // true
Javascript introduced modules system only recently (starting from es6) this practically means that any program is one huge chunk of code, where variables live through out the entire program.
Javascript inheritance system (the Prototypal Inheritance system) is extremely different from classical inheritance systems in these languages, for example in javascript at runtime you can change the the class of an object, at the same time in runtime you can also change the methods of a class.
Now on top of all the technical challenges, notice that there is a product wise decision here, in making RN like this. This enabled RN to go to market faster, and not be tied to certain native language, this means its much more easier this way to support new environments by just transpiling ui controls to the native ui of that environment, and keeping javascript as it is. And on top of that if tomorrow, someone find a way to transpile javascript to java, this tool can be easily integrated into RN pipeline, without affecting the other components and supported environments of RN.

Writing optimised JS for asm.js

There is quite a bit of excitement on asm.js and how it will be able to run some very heavy applications. However, it is compiled from C++ code. Is it still possible to get the benefit of current improvements without knowing C++ or other low level languages?
Here is the thought that I had: Is it at all possible that we can write the code in Js, have it recompiled for asm.js for optimisation?

If you have small function that is very computation-heavy (crunching numbers rather than manipulating DOM) you could rewrite it in asm.js style yourself, manually. It's possible (I've done it), but tedious.
There are other asm.js compilers, e.g. LLJS that you may use instead of C++.
However, asm.js is not magic. You will only get performance benefit when you use language that is much better suited for ahead-of-time optimization than JS. You can't take fully-featured JS and make it faster by running JS VM on top of JS VM, just like you can't make ZIP files smaller by zipping them.

However, it is compiled from C++ code.
It is not. It's a language. Any program can emit text files which contain asm.js code. Emscripten compiles LLVM IR into asm.js, and there are compilers from C and C++ to LLVM IR, but this is only one possible way of getting asm.js code. Admittedly, it's currently the most mature, practical and popular way, but I would not be surprised at all if other asm.js compilers for other languages pop up some time in the future.
Is it still possible to get the benefit of current improvements without knowing C++ or other low level languages?
Well, in theory any language that can efficiently be compiled to machine code ahead-of-time can be implemented efficiently using asm.js, and that includes some rather high-level ones (e.g. Haskell).
But currently, nobody has a working implementation, and I don't expect this to ever become very popular. Right now, if you want asm.js performance, you'd probably write C or C++ code and compile it to asm.js, yes.
Note that the above excludes (among many others) Javascript.The fact that asm.js is a subset of Javascript is convenient in that asm.js code will run on unmodified browsers, but it's not of much use for anyone writing Javascript. asm.js is basically just a thin layer above machine code, with some amends for security and JS interoperability. Compiling JS to asm.js is as hard as compiling it to machine code: Easy if you don't give a damn about performance (just always used boxed dynamically-typed values like an interpreter, and emit calls to runtime library functions), very hard when you do.
In fact, after decades of research into the subject, there's still no example of a highly dynamic language like Javascript, Ruby or Python being compiled into machine code ahead of time and running much faster than a clever interpreter. Just-in-time compilation, on the other hand, is very much practical -- but the major JS engines already do that, in a less roundabout way than compiling to asm.js, then parsing it again and compiling it to machine code.

Asm.js isn't a separate language, but a subset of Javascript. It's just Javascript with a lot stripped out for performance. This means that you don't need to learn another language, though in this case knowing C/C++ might be useful to understand it.

Asm.js is a very strict subset of JavaScript, that can be generated relatively easily when compiling from C/C++ to JavaScript. Asm.js code is much closer to machine code than ordinary JavaScript code, which allowed browsers to heavily optimise for any code written in asm.js. In browsers that implemented those optimizations, your code will typically run about 50% of the speed of a C/C++ program that is compiled to machine code... which may seem slow, but is a hell of a lot faster than any ordinary JavaScript!
However, precisely because it's optimized for machines rather than humans, asm.js is practically impossible to handcode by any human developer... even though it's just JavaScript. While it is technically possible to convert - at least a subset of - ordinary JavaScript to an asm.js equivalent, such a conversion is not an easy task and I haven't encountered any project yet that made any attempt to achieve this.
Until someone achieves such a Herculean task, the best approach to producing asm.js code remains writing your code in C/C++ and converting it to JavaScript.
For more info on asm.js, see eg. John Resig's article from 2013 or the official specs.

Creating a simpler, domain-specific language by restricting the Javascript support in Google's V8?

Is it possible to create a simpler language by restricting the Javascript support in Google's V8? I'd like to embed the V8 engine in my own tool to run dynamic scripts, and like the idea of V8 precomiling the source for speed. However I need to drastically restrict what is possible within the language.
That means no dynamic allocation of data containers (e.g. arrays), no imported libraries, no recursion, no threads. It's more similar in philosophy to Renderman Shading Language than a general purpose language. The 'new' language is thus much simpler, and I'm only considering JS due to familiar syntax and the fact there's a good 'compiler' already (V8). I might also want it to run script code from within Chrome's native code (NaCl) environment, which Google seems to be working to support in V8.
How easy is it to redefine the JS 'grammar', or whatever other code define the language?
My other option is to create a new compiled language from scratch (maybe using LLVM stuff).

For all the features restriction you want, you would need to carry out a major surgery on V8 as V8 is never designed for such a radical modification.
An alternative solution is to invent a JavaScript-like language (with all the limitations you can impose) and compile it into normal JavaScript which then you can run with V8 (or any other JavaScript engine, for that matter). Well-known examples of such an approach are GWT (from Java), Dart, and TypeScript.

Take a closer look at squirrel language :
http://squirrel-lang.org
from description overview :
"both compiler and virtual machine fit together in about 7k lines of C++ code and add only around 100kb-150kb the executable size."
Enjoy!

What is WebIDL and (why) is it important?

The WebIDL spec is in last call and the buzz is that this is a big step for the web. However, I can't find much useful information on it and why it is important.
I understand it defines an interface but an interface for what? How does WebIDL relate to ECMAscript, JavaScript, HTML or the DOM? Will this affect the life of the humble web developer or is it for a different crowd - browser developers perhaps?
Links to articles are welcome.

One area where WebIDL is important is typed language compilers targeting JavaScript. I work on a tool called WebSharper that compiles F# to JavaScript; a much better known example is GWT for Java. In these frameworks our users want typed access to available functionality, with code completion and checking. We used to describe F#-JS mappings by hand or in semi-formal semi-automated ways. It sounds like compiling WebIDL will help a whole lot to be more up-to-date with the evolving HTML5 spec. Ideally we could even convince JavaScript library writers to provide or generate WebIDL for their code.

I would say that it relates to the DOM and ways to manipulate it through languages other than JavaScript. JavaScript already has ways to manipulate the DOM, but that's not a standard, and WebIDL is probably an interface for other languages.

Why is JavaScript sometimes viewed as a low level language?

Inspired by this question.
I commonly see people referring to JavaScript as a low level language, especially among users of GWT and similar toolkits.
My question is: why? If you use one of those toolkits, you're cutting yourself from some of the features that make JavaScript so nice to program in: functions as objects, dynamic typing, etc. Especially when combined with one of the popular frameworks such as jQuery or Prototype.
It's like calling C++ low level because the standard library is smaller than the Java API. I'm not a C++ programmer, but I highly doubt every C++ programmer writes their own GUI and networking libraries.

It is a high-level language, given its flexibility (functions as objects, etc.)
But anything that is commonly compiled-to can be considered a low-level language simply because it's a target for compilation, and there are many languages that can now be compiled to JS because of its unique role as the browser's DOM-controlling language.
Among the languages (or subsets of them) that can be compiled to JS:
Java
C#
Haxe
Objective-J
Ruby
Python

Answering a question that says "why is something sometimes called X..." with "it's not X" is completely side stepping the question, isn't it?
To many people, "low-level" and "high-level" are flexible, abstract ideas that apply differently when working with different systems. To people that are not all hung up on the past (there is no such thing as a modern low-level language to some people) the high-ness or low-ness of a language will commonly refer to how close to the target machine it is. This includes virtual machines, of which a browser is now days. Sorry to all the guys who pine for asm on base hardware.
When you look at the browser as a virtual machine, javascript is as close to the (fake) hardware as you get. That is the viewpoint that many who call javascript "low-level" have. I think it's a pointless distinction to make and people shouldn't get hung up on what is low and what is high.

A lot of people say this because the objects and structures provided in JavaScript are about as simple as you can get. To develop any sort of real functionality, you have to use an external library. Low level is a bad way to put this, because it already has a meaning in computer science. A better way to say it may be that it's without built-in libraries.
Compare this with Java, where the actual language really doesn't do a whole lot. Trying making an array without an ArrayList, or access the file system without the IO libraries. Most languages are more than just the basics, they come with this extra functionality.
With JavaScript, the only real power we get comes from the APIs that are introduced by the browsers and aren't part of the language. Things like DOM manipulation and Ajax are supplied by the browser.
It may be better to summarize all of this by saying that with a language like Java, you can get started doing some serious work without having to download third-party libraries, but with JavaScript, you either have to download a library or write a library of your own.

"Low" here has the same meaning as in the sentences "The number of casualties suffered in the first world war was low," and "Reduced-fat ice cream is low in calories." It makes sense when there's an obvious point of comparison, but out of context, it is simply absurd.

I don't view javascript as a low level language. A lot of functionality and user experience boosters are provided by it. Maybe others may view it as such simply because users can turn it off in their browser options, but it's a hugely robust language that virtually runs the web on virtually all types of browsers...

It's not, it may be as low-level as you can get in normal browser programming, but its on par with functional languages like Scheme or Python.
I think the great lacks of Javascript are lack of name spaces or packaging and no threads

It's low-level compared to the GWT and similar toolkits, but it's not a low-level language in the larger scheme of things. The features it offers are very high-level: closures, dynamic typing, and prototypical inheritance are just a few examples of its high-level features.

It's considered to be low level by a number of people who prefer writing java to generate javascript then writing javascript(ie they dislike it fairly or unfairly). A lot of people complain about java these days but despite the lack of static type checking most people would probably consider ruby and python easier to write in most cases (java being a fairly simple static language-which are much harder to design well without large built-in feature sets then a simple dynamic language).
Few people would call python or ruby low level compared to java and if people were forced to target a python or ruby vm its hard to imagine that a java to python/ruby compiler would become as popular as gwt.
In closing javascript has an image problem(people sometimes think of languages as getting more difficult as they become more low level and vice versa).