W3C adopts WebAssembly

WebAssembly has been adopted by W3C and is now an official web standard. This doesn’t mean it is ready to use, however.

The saga of WebAssembly will probably mystify programmers in years to come. We have browsers that have “native” JavaScript support and this has been refined and evolved over the years. Most programmers don’t like JavaScript for a range of reasons – it’s not elegant, it’s not class based, it’s weakly typed and it’s slow. Over time there have also been attempts to allow programmers to write in their language of choice and have this run in the browser.

While compiling to JavaScript does nothing much for speed, Google’s NaCL which allowed programs to be compiled into native code, permitted running at full speed.  This seemed like a better idea, but no one wanted to get behind Google on this one. Later Google implemented a platform-independent version of NaCL , however it had no more success in being adopted.

The next suggestion was to invent a sub-set of JavaScript that could be used as a browser assembly language – asm JS.This worked but perhaps not with the speed up that was hoped for.

The final approach was to think of implementing a new language that could coexist with JavaScript. This idea involved of a whole new lowish-level language based on syntax trees. The advantage of a language based on syntax trees is that it makes the code quick to execute and you can choose a range of architectures to implement it – for example a stack machine, which is slow but easy to implement.

An alternative would have been to adopt, say, the Java VM and take advantage of the existing compilers and tools. I can see why the web community might not have wanted to use anything connected with Oracle’s approach to Java, but there are alternatives.

Instead what we have is a brand new ecosystem that has to be populated with new tools and at the moment there aren’t very many and they are difficult to use. It is clearly going to be some time yet before WebAssembly goes mainstream.

To be clear – you aren’t going to be writing your code in WebAssembly. You are going to be writing in Python, Julia, R or C and using a compiler to create WebAssembly. The problem is that at the moment the compilers and the associated infrastructure isn’t well developed enough for you to get a junior programmer to do the job. Ultimately it has to get this simple and this polished for WebAssembly to be widely used.

Another interesting choice is the fact that you still cannot dispense with JavaScript. If you hate it then get used to the idea that JavaScript is still very much part of WebAssembly. You need JavaScript to marshal WebAssembly and talk to the UI. A one-language solution is now no longer possible if you want maximum performance. You still have to write substantial parts of any application in JavaScript. The reason for this is supposed to be that having JavaScript handle the outside world makes use of JavaScript’s security mechanisms.

This might provoke a hollow laugh as not only is JavaScript capable of being subverted, adding WebAssembly to it makes things more complicated and hence more vulnerable. The attack surface has just been enlarged. Complexity is the friend of malware.

It is not just the browser that WebAssembly hopes to shake up. The idea is to extend the standard to include environments that WebAssembly can be run under. So I guess the idea is to make it a viable target for every language on the planet, running on every platform on the planet. Sounds unlikely to me.

I can’t help but think that in a few years programmers will see this as a missed opportunity. WebAssembly has many things that are attractive, but the way that it extends JavaScript and has to interwork with it is undesirably complex.

We could have implemented something completely new and completely simple and allowed JavaScript to co-exist or wither depending on the will of the world.

More information


Inspiring readers to embrace the possibilities of the future...