Code corner Like us, you may have heard a lot recently 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.
The beginnings of the web
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.
- Take advantage of common hardware capabilities available on a wide range of platforms (be portable and efficient).
- Make a binary format and a text format.
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.
A Wasm 101
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.
C++ fast inverse square-root code and its corresponding .wat format ... Click to enlarge
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.”
WebAssembly outside of the browser
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:
- Designed as a compile target for multiple languages.
- Compiles rapidly, and supports compilation whilst streaming/downloading.
- Simpler interface policy so more secure.
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. ®
Want to learn more?
Ben James is a freelance software engineer specialising in DevOps. He previously worked for Arm and Cambridge Consultants, and is now pursuing a master's degree at the University of Cambridge. He also works part time for Hackaday.com, producing articles on community software and hardware projects.
In May, Ben will deliver a talk WebAssembly: A threat to Docker? at Continuous Lifecycle London – a conference organized by The Register's mothership, Situation Publishing.
You can find out more, and book tickets, right here.