Back in 2015, a consortium including Google, Microsoft, Mozilla, and the WebKit project announced WebAssembly. This week, Mozilla, Intel, Red hat, and Fastly announced a new consortium called the Bytecode Alliance, which aims to foster WebAssembly and other “new software foundations” that will allow secure-by-default ways to run untrusted code, either inside or outside the Web browser environment.
For many, this raises an obvious question: what is WebAssembly? WebAssembly (wasm) was and is a potentially exciting project, offering a way to run native bytecode inside the browser for potentially very large increases in performance over the Javascript engines in use both then and today.
Javascript is frequently misunderstood as a scripting language that is interpreted at runtime. Although it is generally loaded into the browser as source code, it may be either interpreted or compiled to bytecode and executed. Compilation means higher performance execution—particularly inside tight loops—but it also means a startup penalty for the time needed to do the JIT compilation itself.
There’s actually a whole lot more under the hood with Javascript JIT—including different compiler modes, specialization, optimization, and bailout. Mozilla’s Lin Clark wrote an excellent, reader-friendly explanation for hacks.mozilla.org, if you want more detail.
In the effort to remove that JIT compilation penalty, Mozilla introduced asm.js—a specialized subset of Javascript that is most frequently used as a source-to-source compilation target for heavier-duty programming languages like C. A C language program cross-compiled to asm.js and run as an Ahead Of Time (AOT) compiled chunk of bytecode will (according to Mozilla) typically be within 50% or better of the fully native performance of C code compiled with Clang.
The remaining problem with asm.js is that, as a subset of Javascript, you can’t perform operations or express data in ways that you couldn’t in Javascript. WebAssembly proposes to change this, with native support for 64-bit integers, load-and-store offsets, and direct access to CPU instructions frequently used for specific tasks such as cryptanalysis.
Enlarge / Google Labs’ Squoosh.app uses WebAssembly to let you play with image storage and compression techniques; wipe a bar from left to right to see the difference between original and compressed versions in real time.
Jim Salter
Unfortunately, not much visible has happened in the WebAssembly project since 2015. Even today, it’s difficult to find a concrete example of what WebAssembly can do—support in various browsers is dubious at best, and it’s difficult even to find functional demos to run locally in the toolkit. The most accessible demo we could find was Google Lab’s squoosh, a simple application that allows you to play with various image storage and compression algorithms in real time.
The potential impact of WebAssembly and the WebAssembly System Interface extends far beyond the browser. The Bytecode Alliance envisions a platform that can be used, not only to run native-speed code inside browsers, but in general to make it easier to reuse untrusted code safely across multiple platforms, including server, edge, mobile, and IoT devices.
Listing image by Petrovsky Vladislav