Alon Zakai

(Luke Wagner from Mozilla here.)

> This seems very much targeted at emscripten and not to cross-compilers that start with GC'ed languages like GWT, Dart, ClojureScript, et al.

That's correct, although one could implement a garbage collector on top of the typedarray heap (we have working examples of this). There are some limitations to GCing the typed array manually, though, such as not taking advantage of the browser's ability to better schedule GCs.

Looking further in the future, though, it would be completely reasonable to extend asm.js to allow the super-optimizable use of the upcoming BinaryData API [1] in the style of JVM/CLR-style objects. Again, though, this is speculative; BinaryData isn't even standardized yet.

> It's also unclear to me how this solves the problem of startup time on mobile.

We have several strategies to improve this. The "use asm" directive, in addition to allowing us to produce useful diagnostic messages to devs when there is an asm.js type error, allows us to confidently attempt eager compilation which can happen on another thread while, e.g., the browser is downloading art assets. Looking farther in the future again, we could make some relatively simple extensions to the set of Transferrable [2] objects that would allow efficient programmer-controlled caching of asm.js code including jit code using the IndexedDB object store.

> In all likelihood, the majority of asm.js outputs would be actually be non-human readable output of optimizing…

To remind, the original context was transpiling another language (with semantics that allows irreducible CFGs) to Zig, not just this one specific pattern. Yes, of course, for pretty much all practical code, there is going to be a better equivalent. But the transpiler doesn't get the benefit of only working with practical code - it has to deal with whatever the source language spec says is legal. So you need to come up with a generic solution to the entire class of problems presented. Which does exist - e.g. Relooper (https://mozakai.blogspot.com/2012/05/reloop-all-blocks.html) - but the point is that it is very much a non-trivial transformation, to the point where it might actually be easier to transpile to C or something else that has full-fledged goto that you can just use directly.

Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of them in top JS engines.

Starting fresh would take many more than two years, and very likely end in tears. This assumes browser vendors could spare the effort to do JS and the new thing (most cannot, even Google arguably can't).

For why the best VMs are focused on one language, see

https://www.dartlang.org/support/faq.html#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart

and

https://www.dartlang.org/articles/why-not-bytecode/

from the Dart team. See also

http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web-bytecode.html

from Alon Zakai of Mozilla.

> However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo.

Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages.

Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html

> JavaScript and HTML are a lot more bloat than machine language code written to the wire.

http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html suggests otherwise in a head-to-head comparison: C code compiled to both a platform-native binary blob and JavaScript, then both gzipped (standard practice for any large JS file on the web).

And if you're talking platform-dependent machine code, that's likely _worse_ on the wire in practice, because unlike a platform-independent representation you can't do edge caching or other sorts of intermediate caches. But maybe you meant a virtual machine (i.e. what people ask for when they want a common bytecode)?

> ... it is now utterly controlled by a small group of browser developers ...

If the group is small, it's mainly because the job is very difficult. All browsers are a big mess and it takes time to be productive.

The idea of asm.js is one of Alon Zakai. He explains on his blog all the experiments he made before concluding with that.

A quote from the oldest post I know about emscripten:

"I want the speed of native code on the web - because I want to run things like game engines there - but I don't want Java, or NaCl, or some plugin. I want to use standard, platform-agnostic web technologies."

http://mozakai.blogspot.fr/2010/07/experiments-with-static-javascript-as.html