Ryan Kelly

These are real concerns. Asm.js is not a perfect solution. I am not Alon Zakai, but I'll try to answer to the best of my understanding.

1. Asm.js is not an alternative for a hypothetical high-performance, human-readable language in the browser. Ex: It's not competing with the idea of a C#-in-HTML JIT compiler. It is competing with Silverlight -where the browser is already downloading inscrutable binaries.

2. Emscripten has so far received the most man-years of effort, but the idea of other systems using asm.js as a compilation target is very attractive and it's not so difficult as to be a huge barrier for competition. For example https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ (for a specific benchmark, after jit warmup). Personally, I'm excited about the idea of hooking the emscripten backend into http://terralang.org/ Terralang is a system for building custom, high-performance languages on top of LLVM.

3. Asm.js runs on any standards-compliant JS interpreter with no special support required. Even if the interpreter ignores the "use asm" directive, you can expect to see speed benefits simply from the fact that asm.js code is JS in a style that is easy to JIT very well. In order for phones, consoles, smart TVs ect... to fully benefit, it will of course require the platform holders to put in the effort to respond to "use asm". "Open Platform" doesn't mean "Works perfectly before the platform holder even implements it" ;) Also, Asm.js is not targeted to…

You can absolutely do runtime code generation, you'll just be generating javascript. If you generate asm.js compatible javascript you'll be effectively JITting native code on the fly (you're just jumping through some absurd hoops to do it).

There are some proof-of-concept projects out there that do runtime generation of JS on the fly for things like recompilation and such in the browser right now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library for my compiler JSIL also does a significant amount of runtime code generation to improve performance and reduce executable sizes [3].

[1] https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/

[2] http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/

[3] http://jsil.org/ ; https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe.js#L1254 and others

It's not clear to me why you think that the linked article shows that naive JITs perform better across-the-board than well-written bytecode interpreters. The reported speed improvement from JIT itself is a mere 2.3x, and the listed benchmarks mostly involve numerical code, where JIT tends to be effective.

Relevant post here:

https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/

A simple JIT can get you to the point where you reliably outperform a bytecode interpreter for certain types of code. What takes a lot more engineering effort is reliably performing at least as fast as a bytecode VM for all types of code.