Is WebAssembly Viable Outside the Browser?
In short, yes.
WebAssembly (Wasm) has emerged as a dominant technology that’s taken web development by storm. From early technical demos, like the popular game Doom running completely in the browser, to large legacy apps like Photoshop offering a full desktop-like experience on a regular webpage, WebAssembly offers completely new experiences in a familiar program already installed on every personal computer in the world.
Wasm was designed to allow nearly any programming language to support it regardless of what type of processor the user’s computer has, and it has several favorable security properties that the browser uses to prevent unauthorized access to a user’s data or system resources. It turns out these properties are incredibly useful outside of the browser, particularly when wanting to run code in isolation or that’s ultra-portable.
The story of POSIX on Unix
WebAssembly, by default, doesn’t have access to any resources of the system it’s running on. It’s all just pure manipulation of zeroes and ones, which is why we’ve seen Wasm used primarily for computationally heavy tasks, like decoding video or manipulating images, rather than full-scale app development. It’s relatively easy to give your WebAssembly sandbox access to outside functionality, like information about the current time or data stored in a file, but exactly which APIs are used tends to vary from app to app.
Unix systems experienced something similar to what’s happening with WebAssembly outside of the browser. Many apps wanted access to common system resources, like networking and file systems, but each operating system had a slightly different way of doing it. For this reason, POSIX premiered as a standard portable operating system interface—all Unix-like systems could adopt this interface to standardize how programs talked with the operating system. This also made it so programs designed to work on one Unix-like system could easily be ported to work on another.
Enter WASI, the WebAssembly System Interface
To provide a standard way for WebAssembly programs to talk to an operating system, WASI, the WebAssembly System Interface, was born. WASI was largely inspired by a project called CloudABI, which was in turn inspired by POSIX. This opened up a world of opportunities for WebAssembly to shine outside of the browser—users now had all of WebAssembly’s security and sandboxing properties combined with mindful APIs to access common system resources without completely losing out on sandboxing. Naturally, one similar technology comes to mind—containers. No discussion on this topic is considered complete without a reference to one of the most profound, shared posts about WASI by Docker co-founder Solomon Hykes:
That’s quite the statement. WebAssembly provides a portable way to package code that can be run safely and securely on any platform at near-native speeds, with the added benefit over containers that no operating system needs to be present at all. Most containers developers produce have some sort of Linux operating system that programs run within, yielding container sizes of often hundreds of megabytes or several gigabytes. WebAssembly binaries are pure code, with sizes often in kilobytes or single-digit megabytes. It feels crazy to imagine a world where instead of deploying containers everywhere, developers instead deploy WebAssembly, but this reality is already coming to fruition, with several projects being actively developed to run Wasm on Kubernetes.
Server-side WebAssembly in production
A number of companies are already benefiting from server-side Wasm in production. Cloudflare and Fastly both have massive edge-compute networks that allow customers to deploy code all around the world, as close to users as possible. Both strategically chose WebAssembly to have small, ultra-portable binaries with quick startup times and solid multi-tenancy. An upstart company, Cosmonic, uses clever networking to allow WebAssembly components to seamlessly talk to each other no matter where they’re running, whether that be a tiny device in the palm of your hand or a machine running on the other side of the world. Another upstart, Fermyon, uses WebAssembly to massively increase server workload density. The result is a drastic reduction in server costs and greener computing for the planet.
Growth outside the browser
To summarize, WebAssembly, although initially developed for in-browser computing, has continued to show high viability outside of the browser. Its design, supporting various programming languages and emphasizing security, makes it an excellent choice for running code in isolation and achieving portability. The introduction of WASI has allowed server-side WebAssembly to flourish, enabling organizations to leverage Wasm and provide better products while being substantially more cost-effective. WebAssembly’s potential outside the browser is not just an idea, but a growing reality for the industry.
To learn more, see our previous blog post, “Why You Should Care About WebAssembly.”
Also, watch or listen to our “WebAssembly Unleashed” podcast.