WebAssembly, the portable code format positioned as an option to run any language in the browser, is poised to move from lab toy to production tool.
But there's still a lot standing between now and a Utopian future of language-neutral browser scripting. For one, the WebAssembly toolchain is fairly scant, aside from the compilation tools used to generate WebAssembly images from C applications.
Here are a few third-party tools we've seen springing up for WebAssembly, organized by category and concept, that are worth keeping an eye on as WebAssembly becomes more of a reality.
Decoding/dissassembly
WebAssembly was designed to be parsed by existing JavaScript engines as a bridge to the future. But the binary format used by WebAssembly won't be familiar territory, especially if you're interested in building a compiler for it or generating WebAssembly code on-demand.
A couple of projects have sprung up to provide disassembly utilities. For Python users, there's wasm; for C# users, WasmLib. The former is far more developed than the latter and is showing more activity (sorry, C# fans!). Rust users can check out rust-wasm, although its functionality right now is very limited.
The most polished tools for WebAssembly right now are in -- what else? -- JavaScript, and among them is Daniel Wirtz's toolset for working with WebAssembly by way of JavaScript applications. It includes assembly and disassembly tools, plus convenience classes to represent the structure and contents of WebAssembly binaries.
Language support
Right now, WebAssembly's toolchain is indirect. Language support mainly consists of compiling items to JavaScript via Emscripten, then generating WebAssembly code. As yet, there's no way to directly translate, say, Ruby or Python source code into WebAssembly binaries.
What is possible: Translating the interpreters for those languages, which are typically written in C, then run scripts on top of that. The CPython interpreter, for instance, can be compiled with Emscripten, and the mruby project can do the same for the Ruby interpreter. But this is a bulky, interim solution, and the overhead needed by the interpreter renders it undesirable for anything but experimental use right now.
Nifty and useful
In theory, it's possible to compile WebAssembly to standalone, native executables. WebAssembly Ahead-Of-Time Prototype (WASM-AOT) does exactly that. Its author hasn't intended it to be for production use -- not when WebAssembly is so primordial -- but in the long run, it could serve as a guide for how WebAssembly could work as a true cross-platform compilation system outside the context of the browser.
One problem that emerges with any new technology stack is introspection -- lifting the lid and figuring out what's going on under the hood while operations are running. One project, wasm-metering, injects code directly into WebAssembly applications to measure memory usage and the costs of specific instructions.