What Is WebAssembly?
WebAssembly, or WASM, is the second universal programming language that all web browsers can understand and run. However, you’re not going to be writing scripts in WebAssembly yourself—it’s a low level assembly language, designed to be very close to compiled machine code, and very close to native performance.
WASM is just an intermediary language that is easy to compile to. In fact, it’s almost exactly the same concept as Java bytecode and C# MSIL—both of these formats make it easy to run the same code cross platform, using the same format running on specific runtimes made for each platform.
Even traditional desktop languages like C++ and Rust can be compiled down to WASM with relative ease; AutoDesk was able to port their 35 year old C/C++ codebase over to WASM in a few months, and Google ported Google Earth, both of which render complex 3D scenes and run at near-native performance. The Unity game engine also can run in WASM.
WASM currently runs in 94% of user browsers, with IE, UC browser, and Opera Mini support being the main things holding it back, as per usual. However, it’s backed by developers from Mozilla, Microsoft, Google, and Apple, and its support in modern browsers is fast-moving. Like most web standards, it’s currently managed by the W3C standards organization.
Great, so what does this mean for everyone? Well, while running DOOM 3 in a web browser is certainly a cool demo, it’s not exactly game changing.
How Do WASM Client Frameworks Work?
Since WebAssembly is just a way to run code in a sort of “WebAssembly environment,” you can think of it like running a Docker container. For example, Microsoft’s Blazor framework (by far the most popular WASM client framework so far) has two modes of operation:
- Blazor Server, which runs all the processing and rendering on the server, and sends updates to the HTML DOM over a WebSocket, and
- Blazor WebAssembly, which does the exact same thing, except now the processing and rendering is done on the client, through a .NET runtime compiled for WASM.
Beyond that, WASM client frameworks work in general like any other framework, and the exact details will depend on the implementation.
How Much Faster Are We Talking?
The question of “how much faster is WASM?” is hard to pin down. It’s clearly faster overall, there’s no doubt about that, but in some cases it’s more complicated than that.
Compared to native code, it’s likely to always be slower than the language it’s compiling from. So while it’s probably going to be fast, there are a lot of caveats, and you shouldn’t be using WASM with the expectation of getting native performance on the web.
With that all being said, WASM doesn’t need crazy performance to be revolutionary. It just needs to work, not be slow, and support many languages.
What Frameworks Work Right Now?
The most important one by far is Blazor, being developed by Microsoft. It’s the first WASM client framework being backed by a major company, and will probably be the catalyst for WASM to finally get the mainstream adoption it deserves.
Blazor WASM is only a year old, with Blazor Server being released 3 years ago, but the great thing about Blazor is that it’s just an extension of ASP.NET, a 20 year old web framework that Microsoft has been constantly improving. You can use many frontend libraries already written for ASP.NET, and it’s likely to be the only framework backed by a web package manager rivaling NPM.
This isn’t some side project either—Microsoft has been pushing Blazor as much more than just a web framework; it’s their next application programming model. They’re working on Blazor Desktop, releasing in late 2021, which works a lot like Electron does to run the same Blazor web apps on the desktop. They clearly care a lot about it, which is great news for WASM in general.
The other production-ready framework is Yew, built on Rust, a modern language similar to C++, except with memory safety due to the weird way it handles references. Yew is fast, supports a component based model like React, and has interoperability with JS APIs.
The Future Of WebAssembly
This has all focused on client web frameworks using WASM to manipulate the DOM and build applications. But, you can also just port entire desktop applications to the web. That’s what Uno does—uses WASM to run Universal Windows Platform (UWP) apps directly in a web container, which also comes with the added benefit of being completely cross-platform. It’s actually a bit uncanny how well this works, and really feels like you’re using a native Windows app. You can check it out yourself in their gallery.
There’s a lot more to the WASM ecosystem than just these. If you’d like to learn more, you should read through the awesome-wasm compilation on GitHub, which lists a bunch of popular projects.
The most notable one that we didn’t mention here is WASI—a way to run WebAssembly portably on any system using a standardized system interface. As WASM becomes more and more performant, WASI could prove to be a viable way to run any kind of code on any kind of system, similar to how Docker works but without the restriction on OS. In fact, Solomon Hykes, the creator of Docker, has endorsed it wholeheartedly:
If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! https://t.co/wnXQg4kwa4
— Solomon Hykes (@solomonstre) March 27, 2019
WebAssembly is only a few years old. It still has plenty of room to grow, and is still picking up speed. It’s not unreasonable that five years from now, frameworks like Blazor and Yew will be just as common as React, Angular, and Vue.
This could be argued to be fragmenting the web ecosystem, but WASM is cross platform. WAPM, a WASM package manager, may become the go-to way to share libraries between frameworks of different languages.
In any case, web frameworks running on WebAssembly have huge potential, and with Microsoft personally backing one, we’re confident that they’re the future of the web.