An Early Look At WebAssembly

Thom
August 5th 2016

Keeping on the cutting edge of frontend technology can feel like you're trying to herd cats at times. The huge choice of tooling, libraries and frameworks has simultaneously improved the developer experience and caused a lot of buzz about 'fatigue' and 'churn' with people trying to keep up. In this post I'm going to take a look at what may significantly change how we develop webpages in the future and become The Next Big Thing™: WebAssembly.

WebAssembly is about as bleeding-edge as you can get at the moment. Even the logo hasn't been finalised yet. But before we look at WebAssembly, we need to talk about translating compilers.

A translating compiler (transpiler) is a compiler that can take the source code of a program written in one programming language and produce the equivalent source code for another programming language. For a while we've been able to use transpilers like Babel to convert non-JavaScript code to JavaScript. This allows us to write code in languages with different features or syntax and transpile it to run in any environment that JavaScript can. Typically this is used for compile-to-JS languages like TypeScript or CoffeeScript, but even extends to being able to write code from proposed versions of the JavaScript spec and run it in older browsers. Literally allowing you to write code from the future.

While it's true that Emscripten transpiles to JavaScript, it would be more accurate to say it transpiles to asm.js, a subset of JavaScript designed in such a way that browsers can support running it with similar performance characteristics to the original languages. This brings the performance significantly closer to the corresponding native implementation.

Emscripten allows people to use the language and paradigms of their choice in the browser, but since the compile target is JavaScript (despite the optimisations from asm.js and ahead-of-time compiling) there is still a performance bottleneck.

This is where WebAssembly comes in.

WebAssembly is a specification for a native bytecode compile target. The idea is that you can compile the language of your choice directly to a WebAssembly executable and have it run as true native code. This is great news for people wanting to do 3D rendering, compression or anything performance intensive directly on the web.

Currently, the only way to produce a WebAssembly binary is from a piece of asm.js source. We could use Emscripten to do this, but let's keep it simple and write our own;

This should be fairly familiar. Anyone used to writing in strict mode will recognise the prologue directive for notifying the browser to treat this code as asm.js. The bitfield OR zero operation is used in asm.js to denote integers.

Next we need to download a copy of the WebAssembly toolchain Binaryen and compile it. After compiling, we can use the asm2wasm tool to produce a human-readable representation of the WebAssembly bytecode in the current S-Expression format.

Lisp programmers will probably feel quite at home looking at this syntax. For everyone else, you're looking at a tree representation of the abstract syntactic structure of WebAssembly bytecode. From here, we can use wasm-as to produce our final binary;

After playing around trying to enable the experimental WebAssembly support in Chromium it just won't run for me, even after manually hex editing the binary to try and conform to whatever implementation I have installed.

Being so early in the development timeline of WebAssembly I kind of expected this to happen. Not put off, I decided to try the latest nightly of Chrome Canary.

Hurrah! Finally running native code on the web. I must have been using a more recent version of Binaryen than that is implemented in Chromium. Enabling WebAssembly support exposes a `Wasm` global variable and you can use its instantiateModule method to load your custom WebAssembly binary.

So where does this leave JavaScript now that anyone can write in their preferred language and have it run on the web? One thing to note is that WebAssembly isn't exactly meant to be a replacement for JavaScript, but it will prove to be a much better alternative in resource intensive operations. It is intended that things like complex DOM manipulation will be better suited to being done in JavaScript.

It's very early days for WebAssembly at the moment. Expect support to gradually improve and the intermediate asm.js step to be phased out as tooling develops.