Mozilla has taken concrete, if small, steps to realizing WebAssembly, a next-generation approach to Web browsers supporting scripting in multiple languages.
Based on a recent blog post, Mozilla has produced a working toolchain to compile code into WebAssembly. The toolchain is still a long way from from being casually usable, though. Right now, it consists of multiple pieces back-ended together rather than unified, end-to-end tools.
What's more, all of the work taking place right now won't have any measurable meaning for the user until WebAssembly support actually arrives in the browser.
The first few pieces
Right now, Mozilla's process for getting WebAssembly to run in the browser consists of the following steps:
- If the code in question is C/C++, use the Emscripten tool to compile it to asm.js, a subset of JavaScript designed for high performance.
- Use another tool, Binaryen, to compile the resulting asm.js to WebAssembly.
- Do nothing with the resulting WebAssembly code because browsers don't yet run it.
Obviously, the last step is the biggest blocker; there's no road forward for WebAssembly when no support for it exists in the major browsers.
Mozilla has trumpeted these results all the same, claiming the code passes tests for the WebAssembly's existing test suite. In theory, this means the resulting code will run as-is when browsers get around to adding WebAssembly.
The current toolchain more or less picks up where asm.js left off. Existing projects that compile to C/C++ can be converted to WebAssembly, as can projects already converted to asm.js. But a true one-step conversion process -- C/C++ to WebAssembly, or support for most any other language apart from JavaScript -- is a ways off.
Looking forward
Mozilla is being as forward-thinking as possible when it comes to the toolchain's individual pieces. LLVM, the compiler infrastructure used by language projects from Microsoft's new .Net compiler to the Pyston compiler for Python, is getting a WebAssembly back end that ought to provide some more latitude in terms of how WebAssembly code can be produced.
There's been talk of using LLVM's emitted bitcode as a binary format, but the WebAssembly team claims LLVM's bitcode format isn't really suited to WebAssembly's larger mission of a stable, compact, and portable code format that's quick to decode and compile.
WebAssembly is avoiding a major pitfall that entrapped other attempts to make a universe runtime for the Web: a single vendor behind it all. Google attempted something like this with its Native Client project, but no one except Google -- and no browser but Chrome -- chose to implement it. WebAssembly is a consortium project, with Mozilla taking a role alongside Microsoft, Google, and WebKit.
One of the long-term plans for WebAssembly is to create a runtime that stands apart from the browser. Done right, that means any language compiled to WebAssembly could run across platforms with a single interpreter. Node.js did something similar for JavaScript, but WebAssembly's design makes it theoretically possible to provide the same kind of portability for other languages as well.
Still, the best near-term proof of WebAssembly's viability will come when browser support arrives. Given Mozilla's headlong plunge into the project, Firefox will likely be the first of the major browser vendors to do so, but it has not yet announced a timetable for when that's likely to happen.