I’ve been authoring the WebAssembly Weekly newsletter for just over two years now. As we near the end of 2019 I want to take the opportunity to share some of my favourite articles from the year. From funky demos, to big announcements, this is my 2019 in review …





The year kicked off with an eye-catching demo, a port of the classic Doom 3 game to WebAssembly. This project uses Emscripten to compile the open-sourced C++ codebase, although it certainly isn’t as simple as pointing the compiler at the codebase, there are numerous features that are not supported and this project is an ongoing effort. This demo generated quite a bit of excitement …

Doom 3 running in the browser using Emscripten / WebAssembly https://t.co/4FW1bsPWoA pic.twitter.com/1HtX6OgJ2w — WebAssemblyWeekly (@WasmWeekly) January 3, 2019





The WebAssembly runtime is fast, relatively simple, scalable and secure - it is also host-independent, in other words, you can use WebAssembly as a runtime outside of the browser. This year we saw significant traction outside of the browser, with projects and companies using WebAssembly as a runtime on the server (typically for serverless functions), on the blockchain (as a smart contracts engine) and as a standalone runtime in its own right.

As a result various companies are exploring the best way to allow WebAssembly to perform various I/O operations such as communicate over sockets and access the file system. The industry has teamed up to make this a joint effort, resulting in WASI, a modular system interface for WebAssembly.

The significance of WASI was highlighted on Twitter by one of the co-founders of Docker:

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! https://t.co/wnXQg4kwa4 — Solomon Hykes (@solomonstre) March 27, 2019





Time for another cool demo … CityBound is a city building game that simulates city environments, packed full of peoples, cars, roads and houses. It is a fascinating microcosm and a joy to watch. Better still, the whole game is open source and written in Rust, compiled to WebAssembly.





And more from Mozilla, this post announces Pyodide, an experimental project to create a full Python data science stack that runs entirely in the browser. This project also uses Emscripten.





Blazor started life in 2017 as a fun experiment by Steve Sanderson (part of Microsoft’s ASP.NET team) who was looking to find a way to run C# on WebAssembly. He initially took an old (and abandoned) C implementation of the .NET Common Language Runtime (CLR), compiled it to WebAssembly and found he was able to run .NET assemblies DLLs within the browser. This experiment moved to Mono in 2018 and soon after become an official ASP.NET project.

The project has matured quite rapidly, and this year Microsoft announced that its first full production release will take place in May 2020. WebAssembly is really moving!





It’s demo time again … a fluid dynamics simulation, looks and works beautifully.





14 hours of content compressed into a 20 min read

This year saw the first dedicated Wasm on the Blockchain conference. This article gives a fantastic bite-sized roundup of all the talks. You can also find all of the sessions on YouTube.





I’m going to be cheeky and include one of my own articles - I particularly enjoyed writing this one. The WebAssembly Threads proposal is currently at stage 2 which means that the specification draft is complete and implementations are available. Chrome already ships support for the additional instructions this adds to the WebAssembly runtime. In this blog post I explored how the newly added atomic operations can be used to improve fractal rendering by distributing the task across multiple threads.





In order for WebAssembly to communicate with its host you currently need quite a bit of ‘glue’ code in order to serialise / deserialise complex types via linear memory. The new interface types proposal should remove the need for this glue code making it much easier to communicate with WebAssembly modules, and even allow them to seamlessly communicate with each other.





Most WebAssembly demos are visual, this one is a bit different, it is an audio demo. An experiment in creating chiptunes using AssemblyScript. You can find out more about this project on Peter’s blog.





Wasmer is a standalone WebAssembly runtime. There has been so much cool stuff coming from this team that it is hard to pick any on article for the year. This post announces the WebAssembly shell which allows you to run wasmer modules in the browser. I have a feeling that what we have seen so far from Wasmer is a collection of jigsaw pieces, when they start coming together, and the picture becomes clearer, exciting things will happen.





This was probably the biggest announcement of the year, the formation of the Bytecode Alliance, bringing together WASI and various other initiatives to create a secure environment for execution of third party code. This is a big deal, the team are hoping to fix the significant issues we have seen with vulnerabilities and malicious attacks of modules within npm, crates and various other package managers.





Conclusions

This has been an interesting year for WebAssembly, and I think we are starting to see a subtle change of direction and momentum. A recent survey of JavaScript developers found that only a small percentage are using WebAssembly, and so far we’ve yet to see the killer demo that would make web developers really take note. And why should they? JavaScript running in the browser gives developers a mature (yet ever changing!) environment to work in - there is very little that JavaScript cannot do.

I think WebAssembly will have a far greater impact outside of the browser, despite having ‘web’ in its name.