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.
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.
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.