What's WebAssembly?
WebAssembly is an experimental technology that allows developers to build really fast web applications that run in your browser.
The TL;DR
WebAssembly is an experimental technology that allows developers to build really fast web applications that run in your browser.
You can write whatever programming language you want on your server: but only JavaScript runs in the browser
JavaScript is great, but it can have performance limitations; other languages are usually faster for specific purposes
WebAssembly lets developers write code in faster languages – like C++ and Rust – that still runs in your browser
It’s very early, but there’s excitement around it for performance intensive apps like video editing, gaming, CAD, and AR/VR
Chances are that none of the apps that you use daily are built with WebAssembly, which makes finding examples a bit difficult. But there’s a ton of excitement around it in the ecosystem, and consensus seems to be that it’s going to be a big part of the web stack over the next decade. So read on!
Code that runs in the browser
In any web application (like, perhaps, the one you’re reading this in right now), there are two pieces: the backend and the frontend. The backend is running on some server, or a few, somewhere out there in the cloud. The frontend is running in your browser – be it Chrome, Safari, or Internet Explorer (RIP).
Usually, the backend deals with the world of databases, workflows, and APIs, while the frontend decides what appears on your screen (a table here, a rectangle there) and handles basic interactivity. This paradigm is mostly true for mobile apps and desktop apps too. Here’s a (hopefully) useful diagram from the Technically post about APIs:
An app’s backend can be written in whatever programming language you want. Popular backend languages include Python, Go, Ruby, Java, C++, Rust, and you guessed it, also JavaScript. In your browser though, you can only run one programming language, and that’s JavaScript. HTML and CSS are technically markup languages, and are much more special-purpose and limited in scope. So just JavaScript.
🚨 Confusion Alert 🚨
Two potential points of confusion. First, yes, it’s very popular to have both your frontend and your backend running in JavaScript. The advent of Node.js allowed developers to take their favorite frontend language and build backends with it; and it’s now very popular. Second, JavaScript has no relation to Java. They are completely unrelated languages.
🚨 Confusion Alert 🚨
There are two important things to take away here:
Any web app has important code and functions running in your browser
Any code that’s running in your browser can only be written in JavaScript
Where the problems start – and why WebAssembly exists – is mostly traceable to these two tidbits right here. As browser code has gotten larger and more complex, developers started running into performance issues with their applications. JavaScript isn’t a slow language, but it’s also very high level; there’s no way to get deeper into data type primitives – like strings, numbers, or lists – and as such, you generally can’t optimize it for speed in the same way that you could do so in a language like C++ or Rust. Because of that, code that runs in the browser is usually slower than code running on the server (when your server isn’t in JavaScript).
🔍 Deeper Look 🔍
This framing of WebAssembly – as primarily a way of making browser-based apps faster – is actually a bit reductive. At its core, the technology is more broad, and can be applied in lots of other ways. But for simplicity’s sake, it’s easiest right now to think of it as a web app thing.
🔍 Deeper Look 🔍
This is why performance intensive apps – like Final Cut Pro for video or Ableton for music – can’t and don’t run in the browser. They need to be running on lower level languages to be as fast as their users need them to be. But running in the browser is very clutch! It means you don’t need to develop separate apps for separate operating systems, or even devices. There’s a good reason that most apps you use these days are accessed through the browser; and it’s a shame that many can’t.
And from these ashes…WebAssembly!
What WebAssembly is
In short, WebAssembly allows you to execute non-JavaScript code in your browser, thus quite effectively solving the “damn, I can only run JavaScript in my browser” problem. When you can run C++ or Java in your browser, you can build much faster apps and expand the browser’s footprint; it’s an exciting possibility.
So how do they do it?
The root of WebAssembly is basically a translator – it takes instructions and compiles those instructions into something that a virtual machine in your browser can interpret. There are a lot of new terms there, so let’s break them down:
You write a bunch of code in your language of choice – C++, Rust, Java, whatever
You compile – or translate – that code into WebAssembly instructions
WebAssembly executes those instructions in your browser, inside of a safe sandbox
There needs to be a translation (compilation) layer from a developer’s language of choice into WebAssembly. And since WebAssembly was initially announced in 2015, the communities around programming languages have developed packages that help you do just that – convert a given language into WebAssembly instructions. Each language has at least one, like wasm-pack for Rust, Emscripten for C-based languages, and TeaVM for Java.
🔍 Deeper Look 🔍
The internals of how WebAssembly works are beyond the scope of this post, i.e. I don’t understand them very well. Having said that, if you’re curious, it works as a giant abstract syntax tree, where your instructions to the computer get broken down into flow diagrams. You can read more about it here.
🔍 Deeper Look 🔍
While the WebAssembly ecosystem is developing nicely, it’s hard to understate how early we are here – the developer experience for actually building web apps with WebAssembly isn’t exactly a walk in the park.
Like many important open source projects, WebAssembly isn’t developer or owned by a corporate entity. Instead, it’s a group of contributors called a “working group” that decides on what new features to build and how to build them. There are still tons of important features being worked on or slotted for future work.
How WebAssembly gets used
WebAssembly can be used in a few different ways – the popular one right now is offloading small parts of your applications into it that could benefit from running a bunch faster. Here’s how that workflow might play out:
You have a bunch of JavaScript code in a file that does something
You rewrite that file in a faster language like C++ or Rust
You compile the file into WebAssembly
The WebAssembly runs in your browser very snappily
Once you’ve defined one of these units – or modules – in WebAssembly, you can import it into your JavaScript code in the browser and use it like you would any other function. In that way, you can start to outsource little pieces of your application into WebAssembly, and make them faster.
Please, give us an example already
Let’s imagine we’re building a calculator app that runs in the browser. We want it to look something like this:
Most computations are simple, like, for example, finding 25% of 80, because I still for some reason cannot do this in my head. But some are complex, like trigonometry functions. For the latter, we need to run them on our backend since the browser only lets us run JavaScript, and JavaScript isn’t fast enough for what we need here. But when they’re run on the backend, we need to deal with setting up API endpoints, sending data over the internet, handling authentication…it’s a lot. What if we could run it in the browser, using WebAssembly?
To do that, we first write some code that handles trigonometry functions like sin and cos. Those functions take an angle (x) and return a number:
# using our sine function
var sin_of_90 = sin(90)
# it’s 1, genius
print(sin_of_90)So we write these functions in C++, and use Emscripten to compile them down to WebAssembly. We can then import those functions into the rest of our JavaScript-based frontend and run them – but under the hood, they’re faster, since they’re running in C++. As we add more complex functions to the calculator app, we do the same thing – write in C++, compile to WebAssembly, and use in JavaScript.
This is the main way people are using WebAssembly today, but in the future, entire frontend codebases may be written in languages that compile to WebAssembly. There will probably be entire frontend frameworks that compile to WebAssembly; you may be able to write all of your browser code in whatever language you want. It’s impossible to know where things are going, but it’s exciting.
Further reading
Lin Clark’s cartoon intro to WebAssembly
Information on the WebAssembly community group
A basic tutorial on how to use WebAssembly
Use cases for WebAssembly on their site