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.
Reasons To Be Excited
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).
As with all good tech, there are some tradeoffs to keep in mind as you start to incorporate it with your technology stack.
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.
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.