WebAssembly
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.
It’s by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let’s say. Today I’m pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web. As reflected in the high-level goals, a central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version run efficiently on current browsers using a client-side polyfill. As demonstrated, the polyfill can leverage asm.js to get great performance. For existing Emscripten/asm.js users, targeting WebAssembly will be as easy as flipping a flag. Thus, it is natural to view WebAssembly as the next evolutionary step of asm.js (a step many have requested and anticipated).
