Browsers have gotten much better at parsing and executing JavaScript over the years. But even with the use of just-in-time (JIT) compilers and other optimizations, JavaScript in the browser is still not as fast as native code. This may not be a big deal for many applications, but for those that are computationally heavy, being able to have native speed performance would be a huge win. Video games, for instance, or virtual reality, or working with video or audio—these can all be done on the web, but in the past their performance couldn’t compete with apps running natively. But a new standard has been coming onto the scene that could change all that.

Enter WebAssembly

In 2015, Mozilla announced that they were working with Chromium, Edge and Webkit to create a new standard called WebAssembly.

One of the high-level goals in creating this new standard was to define a portable and efficient binary format that could serve as a compilation target for the web (as well as other platforms). Not only would it be fast—able to be executed at native speeds—but would also integrate well with the existing Web platform. This integration includes working with and through JavaScript, as well as having a human-editable text format that could be converted to and from the binary format, thus making the ability to View Source a possibility.

Why a new standard? Performance was a key motivation:

The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience. (source)

Overall, there are plenty of things to like about all this:

  • The binary format will allow it be smaller over the wire, thus reducing time for the network request.
  • The fact that it’s compiled will save the browser time upfront since it will not need to parse it.
  • The human-editable text format will allow developers to write, view, and debug the code by hand.
  • It’s not a replacement for JavaScript, but rather one way to complement JavaScript, so it can be dropped in as needed without breaking the existing ecosystem.
  • Programs written in other languages (C, C++, Rust, etc.) can target the web by being compiled to WebAssembly.
  • And, there’s buy-in and involvement from all the major browser groups. It’s already shipped in Edge, Firefox, Safari (including iOS Safari), and has over 74% support globally.

Use Cases

Since there are performance benefits to be gained, and plenty of support for this new standard, when does it make sense to use WebAssembly?

In an interview from 2015, Brendan Eich, the creator of JavaScript, gave an example of what they were trying to do through the new standard:

“So rather than kill JavaScript, which is not feasible, what I’m trying to do is respond to real engineering problems that we’ve had with ASM.js. Loading a big game from Epic or Unity can take 20 - 30 seconds. That’s too long. With a compressed abstract syntax tree encoding that’s 20 times faster, just a couple seconds, that’s what you want.” –Brendan Eich

Video games are a prime example where WebAssembly could be, and is already becoming, extremely useful. Virtual reality and augmented reality are also clear use cases, as are audio and video streaming and editing. In many of these cases, there are already codebases written in other languages that could compile to WebAssembly, and thus bring native performance to the web.

But use of WebAssembly could also be used on a smaller or more granular scale. Since it works in conjunction with JavaScript, you could easily have an existing web app, using HTML/CSS/JS, that uses bits of WebAssembly here and there to help with computationally heavy processes (e.g. graphing, image/sound/video processing, visualization, etc.), adding it in as needed.

Although it’s possible to write WebAssembly by hand, it’s unlikely that this will be done much on larger codebases. Rather, the goal with the standard was to provide a compilation target, allowing other languages access to the web platform.

Initial Thoughts

There are several things I like about what I’m seeing. In addition to the performance gains, I was especially pleased to see 1) the human readable text format as part of the standard; and 2) the effort to integrate as well as possible into the existing web platform.

As a web developer, the ability to View Source has been extraordinarily helpful over the years, and one of the things I like about the web. Knowing that WebAssembly is opening up the web as a target for more languages, but doing so in an open way that still allows developers to look under the hood, is great.

I also like that it’s not trying to replace what’s already there. Instead of competing with JavaScript, it’s in many ways extending JavaScript, allowing it to outsource the parts that need native code speed. JavaScript isn’t going away anytime soon, and now with WebAssembly, there are even more options at its disposal.

Learning More

If you’re interested in learning more, here are some places you can start:

  • A cartoon intro to WebAssembly, by Lin Clark – This series of articles was helpful in providing an overview of WebAssembly, and its relationship with the JavaScript and the browser.

  • WebAssembly.org – Includes and overview and docs. The FAQs are a good place to start.

  • WebAssembly on MDN – As typical, the MDN web docs provide plenty of useful guides and reference material.

  • Awesome Wasm – An extensive list of resources, and other things, related to WebAssembly.