WebAssembly, your browser’s sandbox

We’ve been doing web development for 30+ years and in all that time have you ever stopped to think, “This SPA needs more C++”? Well thanks to the power of WebAssembly you can finally bring C, C++, Rust, Go and other high level languages to the browser.

So does this mean that we can replace our JavaScript with these other languages? Probably not, so what is the role that WebAssembly can play in building web applications? And most importantly, what does it look like as a web developer to try and incorporate these platforms that have traditionally been on the server?

For this talk, we’ll look at some of the fundamentals of WebAssembly, how to incorporate it into our development process and ultimately what it looks like to build an application that uses a mixed development stack.

Kicking off with a WAT hello world example that was far too long to write down 😉 You can see the general vibe by looking at other hello world examples for WASM. The take away is that you have to do a lot of really low level stuff you’re probably not used to.

WASM is not the most readable language! Assembly languages are pretty complicated in general and not so accessible to most people. There is a reason compiled languages are popular.

But let’s step back and really start with What Is WebAssembly? It’s the evolution of asm.js, which was created to enable high-performance applications to run in the browser. asm.js was designed as a compilation target rather than a language you write by hand.

WASM is also designed as a target and not a language most people will write by hand. With WASM you end up with a compiled WASM binary written in some other higher order language.

The browser needs more C++ in it. – No one, probably ever

So what does WASM mean for JS devs?

It’s not a JS replacement. It’s possible to effectively replace JS, but it’s probably not the right way to go. Another platform tried to do that… it was called Flash. Browsers are really good at executing JS; and JS is great for things like DOM manipulation. WASM is good at other things. They complement each other.


  • Module – WASM binary
  • Instance – a running WASM module running in a VM in the browser
  • Memory – an ArrayBuffer shared between JS and the VM. It only stores values. This does allow values to be passed between modules.
  • Table – like memory, but for function references

But why? Why would we use it?

  • Sandboxing – the more we build in the browser, the more risks there are (security, stability, memory leaks). Running in a dedicated memory space helps address that.
  • Shared client & server – not every server app is going to be written in JS, because it’s not the best language for all problems.
  • Image manipulation – eg. when we want to edit a photo. There are great libraries in C++ which we can compile to WASM and use in the client and server without differences.
  • Complex maths – WASM is better suited to heavy mathematics than JS

So what is it like to developer with WASM?

  • First, pick your language… something like C, C++, Rust, C#, F#, Go. Aaron picked Go as he wanted to learn it and it was a good opportunity.
  • Convert to a web application… Webpack is well suited to transpilation tasks, so Aaron used that
  • Create a UI over the top… React works well, although you can use anything including gasp raw HTML

Demo: oz-tech-events.aaron-powell.com (github.com/aaronpowell/oz-dev-events, see also Aaron’s blog series behind the demo)

This was a super quick look at WASM. It’s here, it’s real, it’s in browsers. Be aware the binaries can be pretty big so think about appropriate cases to use it.

Use WASM to extend your app. Sandbox parts of the app that could benefit from being sandboxed; or push something to the client that could previously only be done on the server. Look at places it would be useful to reuse code.

While JS is great it’s not the best language for all cases – each language has its strengths and weaknesses.