Brendan Eich: From ASM.JS to WebAssembly |
tl;dr Im burying the lede with context and catch-up material first, so impatient or already-clued-in readers should skip to below the videos for todays big news. Or just read Luke Wagners blog post right now.
My Fluent 2015 ECMAScript Harmony: Rise of the Compilers talk given on April 21st:
Jeremy Ashkenas picked up this ball and ran into the next fields end zone two days later in Brooklyn:
My slides for the talk I gave at ModernWeb.tw on May 15th:
Perhaps you detect a theme, beyond JS turned 20''. Something about compilers rising, Java bytecode and asm.js, shared memory threads and SIMD. The usual retort, recurrent on Hacker News, looks like this:
In an HN sub-thread sparked by my ModernWeb.tw slides, I concurred with Patrick Walton on analogies between browsers and the Unix kernel, JS and C. One does not get to write kernel code in any language, at least not yet. Elsewhere in that sub-thread the analogue of JS was identified as architecture-specific assembly code, where the CPU architecture is fixed by physical reality, while software is written in virtual languages compiled to machine code, or run through interpreters.
In any event, whether analogous to C or assembly, JS has had a lock on the kernel of the client side. Web userland code, in contrast, can be written in a great many languages. Adding a second (bytecode) syntax has looked like a now you have two problems loss, against the alternative of one syntax. Until now.
Its by now a clich'e that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, lets say. Today Im pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
What: WebAssembly, wasm for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JSs semantics, in order to best serve as common object-level format for multiple source-level programming languages.
Its crucial that wasm and asm stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support. Examples of possible longer-term divergence: zero-cost exceptions, dynamic linking, call/cc. Yes, we are aiming to develop the Webs polyglot-programming-language object-file format.
Why: asm.js is great, but once engines optimize for it, the parser becomes the hot spot very hot on mobile devices. Transport compression is required and saves bandwidth, but decompression before parsing hurts. A secondary consideration: JS has a few awkward corners even in its asm.js subset. Finally, once browsers support the WebAssembly syntax natively, JS and wasm can diverge, without introducing unsafe or inappropriate features into JS just for use by compilers sourcing a few radically different programming languages.
See the FAQ for more nuance and detail. No, JS isnt going away in any foreseeable future. Yes, wasm should relieve JS from having to serve two masters. This is a win-win plan.
How: If you use Emscripten, then wasm support via a command-line flag will at first include and target the prototype polyfill. But as native wasm decoders appear in top engines (see the V8 native prototype decoder), Emscripten will auto-configure for best results. Another prototype: a JS AST compressor (encoder).
These prototypes will evolve and track draft specification changes as WebAssembly matures and receives progressively more developer testing. Other compilers than Emscripten, and other compiler frameworks than LLVM, will join the mix. I expect all engines will support fast native decoders. All these parts are means to the end of a common WebAssembly standard.
Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. Im sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.
Here you can see JF Bastien of Googles PNaCl team barely able to keep a lid on the secret. Good thing I replied with a comic book reference as plausible cover. Close one!
