Code corner Like us, you may have heard a lot recent about WebAssembly. Today, freelance software engineer Ben James walks us through its creation, its current state, and the role it will play in the future of cross-platform development.
But now it's 2020. People are cramming more and more into the browser. More content, more graphics, more ads, higher resolutions. And why wouldn't you - if you're a company developing a new application, why make it native?
If a web app can offer the convenience of no installation, no occupied disk space and, most of all, only one codebase to maintain for all platforms, there's really no reason not to make your product/application in the browser. Consider all of this, along with the rise of the Single Page Application (SPA), and it's easy to see how critical browser performance is to the modern web.
Another goal is to support non-browser embedding; i.e. being able to run outside the browser. This is quite exciting - we'll come back to this later. For now, let's take a look at the basics of how WebAssembly works.
The good news is that you can use WebAssembly without ever writing any, since you can simply compile to it from languages like C/C++ and Rust. Other languages are possible too, but it's easiest to start from a language with fairly explicit memory management.
As a result of being able to compile C/C++ to Wasm, it's possible to migrate existing codebases or logic to the browser. For example, AutoCAD and Figma both embraced WebAssembly, and reported great performance results.
But WebAssembly's allure doesn't stop at the browser. More recently, people have realised that a language at a lowest-common-denominator level in terms of hardware and optimisation can be useful in a lot of different places. In fact, Docker founder Solomon Hykes once tweeted: "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker."
Yes, I know, it sounds like we're going in for Java round two. But Wasm is suited for portability across the browser/server in a number of key ways that the JVM isn't:
All of this makes Wasm uniquely positioned to provide benefits to other runtimes. If you have an application that's written in something like Python or PHP, WebAssembly can provide dramatic performance increases, with the ability to run at near-native speed. If you're using something like C++ or Rust, the sandboxing which is provided by WebAssembly at very little performance cost can improve security enormously.
People had speculated about Wasm's use outside the browser, but it didn't become practical until WASI was announced, in March 2019. If we want to run WebAssembly outside of the browser, it's only going to be useful if it can access basic things like files and network in a platform-independent way.
These capabilities weren't initially built into Wasm, because it was intended for the browser. WASI stands for Web Assembly System Interface, and is a modular API which provides access to system calls across different OSes.
At this stage you could be forgiven for being cynical: if Wasm really is all that is promised, why don't we see it in use more often? The answer is purely time; WebAssembly is still in its infancy and new runtimes, toolchains and examples are being released all the time.
So while you might struggle today with the support available to implement WebAssembly in a production system, very soon it will be an attractive option - as someone who's been following WebAssembly for a while, I can say that Wasm is evolving extremely rapidly, and new information and changes occur weekly. ®
Fluent, fluent everywhere but not a patch that works
I'll take a Big Mac, large fries and... um, are you OK?
Unfortunate timing - the Obama admin also supported the database giant
And that's one hell of a privacy agreement
Linux Foundation hears your gripes about naming schemes, legacy code, and more
It's not a bug, it's a feature, explains the Chocolate Factory
PARC, Apple and Amazon - computing pioneer dies at 74