A Glimpse into WebAssembly

WebAssembly opens up the playing field, allowing any language with the right tooling - not just JavaScript - to be executed in the browser. See why this is something you should start exploring.

What is WebAssembly?

WebAssembly is one of those tech buzzwords that is starting to make the rounds. Before you jump to the conclusion that it's one of those trendy topics that should be ignored — or that it's going to change your life — we are going to go over exactly what it is, what it isn't, and why you should be starting to get excited about it. To begin, we are going to start with the formal definition from webassembly.org:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. It's designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

In practice, the best way to think about WebAssembly is that it is a packaging format for code that has been compiled into a portable format that can be used by either frontend or backend code. At this time, there are a few compilers that can turn your language of choice code into WebAssembly.

The really exciting part about all of this is, if you think of JavaScript as the language for web browsers, WebAssembly opens up the playing field and allows ANY language (with the right tooling) to be executed in the web browser.

Reasons To Be Excited

The true benefit comes from WebAssembly's ability to do streaming compilation. Since it was designed for the web, it can start compiling as soon as the data is received on the client without waiting for the entire file. This is a significant improvement from how JavaScript works, which has to wait until the entire file is received before it begins. As your JavaScript file increases in size, it slows down your page in two ways: longer to download the file, and longer to parse the JavaScript which increases the time to First Meaningful Paint (FMP). The streaming compilation allows you to bypass both of these traditional JavaScript pitfalls. WebAssemby's streaming ability is a huge game changer for page paint times and time to interactive. You'll see the page rendering out while the download of the file is still going on.

WebAssembly is open to any language that can be compiled down to the shared assembly, which can open the doors to code reuse between frontend and backend codebases. The ability to have a single language for frontend and backend used to be one of the great pillars of Node, which can be opened up to any language going forward. Of course, this is highly dependent on tooling that allows the languages to be compiled down to WebAssembly (e.g. Blazor, Yew).

Along with code-sharing between teams, WebAssembly shares memory space with the JavaScript engine to allow functions to be exported/imported across the code bases. This seems like a side note, but it's huge. I think this will allow for greater adoption since code can be migrated a little bit at a time without undertaking a huge shift within the team.

Potential Pitfalls

As with all good tech, there are some tradeoffs to keep in mind as you start to incorporate it with your technology stack.

One of the biggest features WebAssembly has been touting is performance. While the overall performance is trending to be faster than JavaScript, the function-to-function comparison shows that JavaScript is still comparable in some benchmarks, so your mileage may vary. When comparing function execution time, WebAssembly is predicted to be about 20-30% faster than JavaScript, which is not as much as it sounds since JavaScript is heavily optimized. At this time, the function performance of WebAssembly is roughly about the same or even a little worse than JavaScript — which has deflated my hopes in this arena.

Since WebAssembly is a relatively new technology, there are probably a few security exploits waiting to be found. For example, there are already some articles around exploiting type checking and control flow within WebAssembly. Also, since WebAssembly runs in a sandbox, it was susceptible to Spectre and Meltdown CPU exploits, but it was mitigated by some browser patches. Going forward, there will be new exploits.

Also, if you are supporting enterprise clients using IE or other older browsers, then you should lean away from WebAssembly. It is still not supported within IE. There has been some early work on polyfills to bridge this gap in IE and older browsers to speed up adoption, but it has slowed due to the quick adoption in browsers of the existing standard.

Another thing to keep in mind is that WebAssembly is still client code, so you should still keep it safe and sanitized. Despite being compiled down, you should still avoid placing any server secrets or user secrets inside of the WebAssembly.

Good Place To Start

If you are wondering where and how to start using WebAssembly in your current web app, there are three areas of your system that would be great starting points.

The first area is looking at the surface area between your frontend and backend code. This is a great opportunity to split any shared code into its own library to be hosted as a .wasm on your CDN or used in your backend process. For some React/Angular apps, it is pretty common to have some shared code between frontend and backend. For e-commerce apps, pricing is always computed twice — once for the client as a preview, and the second time by the server to verify the pricing matches what the user saw on the frontend. Ideally, this code would be written once and just used where needed despite the language, which makes it a great candidate for WebAssembly.

The second starting area would be when taking a new look at an existing project. For example, as a .NET developer, if you want to make some progress toward a single-page application (SPA) without retraining your team on Angular or React, you can start using WebAssembly to aid in that goal via the Blazor framework. Imagine building a SPA with all patterns and tools of .NET with all the benefits of a statically hosted page as the end product.

For the third area, as you start new web-based projects around image manipulation, data visualization, or anything highly interactive (games, charts), it is worth looking into starting with WebAssembly as the deliverable. Unity is pushing WebAssembly to be the default bundle for their clients due to performance (startup and runtime), and there is no reason that you shouldn't as well.

Wrapping Up

So, should you drop everything you are doing today and start on the migration to WebAssembly? No, not yet. There are some folks looking into using WebAssembly with some of our favorite frontend frameworks as we speak, which is where you'll see the biggest gain in performance in the near future. That is when I will actually start to feel enthusiastic about WebAssembly.

Is it something that you should start exploring? Absolutely. I think that WebAssembly is going to give a bigger performance boost to web apps than micro-tuning bundle sizes. Also, it may even give server-side rendering (SSR) competition as the way to serve pages faster.

Stayed tuned. I suspect we'll hear more about WebAssembly and improvements to its features soon.