Blog

WebAssembly: How and why

How to run native code in the browser, why would you do that, and what does it all mean for JavaScript and the future of web development

In every browser, whether you use Chrome, Firefox, Edge, or Safari, the code is interpreted and executed by a JavaScript engine — which only runs JavaScript. Unfortunately, JavaScript is not ideal for every task we want to perform. That’s where WebAssembly steps in.

WebAssembly is a new type of code that can be run in modern browsers. It was created to get better performance on the web. It’s a low-level binary format that has a small size, so it’s fast to load and execute. You do not write WebAssembly, you compile other higher level languages to it.

 Despite its name, WebAssembly is not quite an assembly language because it’s not meant for any specific machine. It’s for the browsers, and when you’re delivering code to be executed in the browser, you don’t know what kinds of machines will your code be running on.

WebAssembly is a language for a conceptual machine that’s the least common denominator of the popular real world hardware. When the browser downloads the WebAssembly code it can quickly turn it to any machine’s assembly.

 This is what WebAssembly looks like — it has a textual format that’s easy to read (.wat), but binary representation is what you actually deliver to the browser (.wasm).

What will WebAssembly be used for? 

Among other things, it will be easy to express things like threads and SIMD — a fancy word that means you can line up multiple chunks of data next to each other and invoke a single instruction to operate on all of them at the same time. It stands for Single Instruction, Multiple Data.

That means fat, parallel processing pipelines for your real-time video stream effects processor. If you have your finger on the pulse, you’ve probably already heard of doing this in JS, but I’ve always found it a bit awkward to try to do low-level stuff like this using JavaScript’s existing type system.

This is one of those cases where you’ll probably want to forget about the object system, the garbage collector, and all the fancy dynamic stuff. Just line up some raw bits in little rows and crunch through them as fast as possible.

What WebAssembly brings to the table?

Here’s what makes WebAssembly special and such a good fit for the web:

  • speed
  • portability
  • flexibility

WebAssembly was designed for speed. Its binaries are much smaller than textual JavaScript files. Because of their size, they are faster to download and this is especially important on slow networks.

They are also faster to decode and execute. JavaScript is a dynamically typed language, variable types don’t have to be defined upfront and it doesn’t need to be compiled ahead. This makes it easy and fast to write, but it also means that the JavaScript engine has a lot more work to do. It has to parse, compile and optimize the code as it’s being executed on the page.

Parsing JavaScript involves transforming plain text to a data structure called abstract syntax tree (AST) and turning that into binary format. WebAssembly is delivered as binary and decoding it happens much faster. It’s statically typed so, unlike with JavaScript, the engine doesn’t need to speculate during compilation about what types will be used. Most of the optimization happens during the compilation of source code, before it even gets into the browser. Memory is managed manually, just like in languages like C and C++, so there’s no garbage collection either. All of this gives better and more reliable performance. The execution time of WASM binaries is just 20% slower than the execution of same native code.

One of the main goals in designing WebAssembly was portability. To run an application on a device, it has to be compatible with the device’s processor architecture and operating system. That means compiling source code for every combination of operating system and CPU architecture that you want to support. With WebAssembly there is only one compilation step and your app will run in every modern browser. 

What’s to come?

The browsers are already working on new features. Support for threading and garbage collection is coming, which will make WebAssembly a more suitable target for compiling languages like Java, C# and Go. One of the important goals is also creating debugging tools that support source maps which would allow developers to easily map WebAssembly to their source code.