WebAssembly (WASM) has been a buzzword in the past few years. It's a technology that raises a lot of attention but is less widely used in practice. I've been curious about its current status, so I investigated and summarized my findings. Some of them may surprise you.
Background
Javascript was the only programming language supported by web browsers until the WebAssembly standard came out. However, WASM was never created as a replacement for Javascript, and it can't because the language is so low-level. Instead, it's specifically made to complement Javascript and addresses its performance issue when conducting computation and memory-intensive tasks - video editing, gaming, CAD, etc.
But, as it evolves, some interesting and unexpected side-effect scenarios are also enabled, as you'll see in this article.
A few quick notes before we move on:
- You don't write WASM directly. Instead, you use high-level languages like C++ or Rust and compile to WASM.
- It's stored in a compact binary format (like machine code).
- It executes in a secure, isolated sandbox.
- By itself, it doesn't do much except crunch large batches of numbers fast. There's no network, no file system, and no DOM access.
What people are building with WebAssembly can be split into two categories: in the browser and on the server.
In the Browser
People use WebAssembly in browsers mainly for three reasons:
- Optimize performance for computation and resource-intensive tasks.
- Migrate legacy native apps to web apps.
- Allow languages other than Javascript to run in the browser.
Let's explore a few great successes for these use cases.
Figma
If you're a UI/UX designer or a dev who messes with your design from time to time, you couldn't have missed Figma in the past year. It's a fantastic product that demonstrates the state-of-the-art performance a web app can have today.
WebAssembly is one of the secrets to Figma's success. To many people's surprise, though a web app, Figma's editor is written in C++, even before the dawn of WebAssembly. How is that possible, given Browsers only executed Javascript? The answer is simple; the C++ code is transpiled into Javascript before delivering to the web.
But why not Javascript from the very beginning? The crucial difference is how the C++ code is transpiled to JS. Javascript is a very dynamic language. To make it run fast, browser engines do a lot of magic to optimize it on the fly. However, the result is still suboptimal and unpredictable. There's a way to gain better performance with Javascript - write the code more like how you use static languages so that it's easier for the engines to process. Figma initially used "asm.js" to achieve the goal - it's essentially a transpiler that turns C++ code into Javascript code in a performant fashion.
However, in the end, it's still Javascript code, it's not compact to load through the network, and the browser still needs to parse its text. This is where WebAssembly beats the previous approach. WASM is a machine-oriented code. It's much more compact than Javascript and incurs a much lower cost for a browser to process. By migrating from asm.js to WebAssebmly, Figma got a 3x performance gain.
AutoCAD
As a product created in 1982, AutoCad is older than the Web and monstrous in size - it has a whopping 15M lines of C++ code. It's been wanting to move to the web for quite some time, but rewriting everything with Javascript is just impractical: lots of work and a much slower result product. Finally, WebAssembly came as the savior.
In many ways, AutoCAD's use of WebAssembly is similar to Figma, except it had the extra problem of a tight dependency on Windows OS to resolve. However, it's still amazing to see that WebAssembly, as a relatively new technology, is feasible to support such a large and complex application and give it a fresh look in the modern era.
By the way, Adobe Photoshop also moved to the web with the help of WebAssembly.
Microsoft Blazor
Blazor is Microsoft's offering to develop a web frontend with its primary backend language - C#, through WebAssembly. As its slogan says, the goal is to build full-stack web apps without writing Javascript, but why? The thought is probably that Microsoft developers love C# so much and want to use it everywhere.
// A Blazor component
@page "/counter"
<PageTitle>Counter</PageTitle>
<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
// C# below
@code {
private int currentCount = 0;
[Parameter]
public int IncrementAmount { get; set; } = 1;
private void IncrementCount()
{
currentCount += IncrementAmount;
}
}
Folks who have been close to Microsoft's ecosystem will likely ask immediately: is this Silverlight revived? No, it's not. Silverlight is a proprietary technology, requires installation, and doesn't have universal browser support. Instead, Blazor is based on WebAssembly, which is now part of the web standard.
Although its value proposition is a bit weird, Blazor is an excellent demonstration of WebAssembly's potential to bring more programming languages to the browser. I don't think any such effort can threaten Javascript's domination, but there can be interesting niche scenarios where this is very useful. For example, with python running directly in your browser, you can use Jupyter notebook without running a local python server:
On the Server
WebAssembly's creators probably had in mind the possibility of running in non-browser environments when creating the technology, but the enthusiasm from server-side developers is quite beyond their expectations.
The excitement is understandable - WebAssembly offers an ideal way to execute untrusted code on the server - it's portable, easier to secure, uses much less memory than JVM or Docker, and is a natural target to compile many high-level languages to. It may not mean much for long-running web server processes hosted in your IDC, but it can be beneficial for some scenarios:
- Serverless hosting providers who need to run short-lived routines for their tenants on a vast scale - quick start, low footprint, and sandboxing are critical.
- SaaS product that supports running user or community-provided plugins
- Edge environments where resources are very tight
The creation of the WASI specification starts the bloom of server-side WASM. WASI is a peer specification of WASM that aims to standardize how WASM code interacts with its hosting environment. In the browser, this wasn't necessary because WASM is an augmentation to Javascript, which already has access to its hosting environment (the browser) through DOM, BOM, and Web APIs. When on the servers, WASM is on its own, and it's not very useful if it can't interact with its environment.
If you're interested in real-world progress, check out the following companies that wrap server-side WASM into services. As the technology matures, they may become serious challengers to traditional container-based PaaS/FaaS vendors. The cloud business has longed for a small, portable, secure application runtime for quite some time.
Cosmonic
Fermyon
Cloudflare WASI Support
Announcing support for WASI on Cloudflare Workers
Today, we are announcing experimental support for WASI (the WebAssembly System Interface) on Cloudflare Workers and support within wrangler2 to make it a joy to work with
blog.cloudflare.com
What's Next
WebAssembly is still a young technology. On the browser side, the use cases are solid. However, it still needs to evolve into a more pleasant thing to develop with - today, you can't load WASM directly like an ES module, and complex Javascript glue code is necessary to interface it. On the server side, it's even more immature, and its values are debatable. It awaits major industry players to put their bets on it and accelerate its adoption.
It's going to be interesting to see how further WebAssembly will push the boundary of web development in 2023.
P.S. We're building ZenStack — a toolkit for building secure CRUD apps with Next.js + Typescript. Our goal is to let you save time writing boilerplate code and focus on building what matters — the user experience.
Top comments (10)
Awesome post!
There are also a few fantasy consoles to track: wasm4.org and gamercade.io
We also recently opened up NanoBus (but haven't talked about it anywhere yet) github.com/nanobus/nanobus
Thanks for the pointers . I’ll check them out!
It would also be nice to add to Wordpress Playground the way to run WordPress entirely in the browser, without the need for a PHP server; everything runs with SQLite and a compiled version of PHP with WebAssembly.
It is useful for demos of themes or plugins, and also for changing WordPress versions quickly without having to make changes to a server.
Awesome! I'll check it and see how to include it in the post. Thanks!
Happy to see Blazor in your post :)
Yes, you can't miss Blazor when researching WASM 😄. How do you feel about it?
I saw Blazor during one of MVP summit in Seattle and it was in a really alpha version.
I spoke about it since a while.
I love it.
Cool. I only looked at its surface. Will find time to play with a real example then.
If there were no TS I would love to code frontend with C# 😄
Really good & informative post, I really liked the examples and the comparisons you gave.
Thank you, @michalispapamichael . I'm glad you feel it helpful!