> Please use a noun. What "That" did you mean? If a hypothetical bytecode were designed, a compiler from this bytecode to asm.js would be just as fast in brows

> Please use a noun. What "That" did you mean? If a hypothetical bytecode were designed, a compiler from this bytecode to asm.js would be just as fast in browsers without support for this bytecode (or for that matter asm.js) as asm.js is currently. One would compile C/C++ to this bytecode and either ship it directly (to browsers that support it) or compile to asm.js and ship that (to browsers that don't support it). This process I described is precisely how Dart works and while I don't particularly like Dart itself, I think its compilation/distribution mechanism is nice. It's possible to do this later, after (and if) asm.js becomes popular. And it would even possible to eventually compile JS itself to this bytecode. > But as the blog post shows, AOT in Firefox is even faster at startup (and see the link on "throughput" for other wins). I am not immediately concerned with the merits of asm.js as implemented in Firefox at the moment. > Missing features are not being added to JS for the sake of asm.js. I clearly wrote we are adding SIMD, int64, etc. for hand-coded JS users. Ecma TC39 is not only concerned with "compile to JS" use-cases, we look at apps, libraries, and compilers. Sure, I guess. These features just seemed to me more important for asm.js than generic application JS (as opposed to, say, macros).