Why WebAssembly Modules Could Be the New de Facto Unit of Compute

You may have heard about WebAssembly at some point over the past few years. It’s been called “the fourth language of the web browser,” and while that is one way to look at it, it certainly isn’t even close to the whole story. Since WebAssembly is actually a platform-agnostic binary format for executables, talking about where it runs is just as important as what it does. Over the past year or two, WebAssembly has blown past the browser and is now lending its strengths to other domains such as embedded systems, IoT, and server-side development.

I’ve been working on the cloud native WebAssembly framework Atmo for about a year now, and the possibilities I laid out here have me very excited about the future of the ecosystem. I see advancements every week, with new open source projects and cool use-cases popping up everywhere.

It’s well known that the past decade has seen the software industry shift from bare metal to virtual machines to containers. The current era has many forms of cloud compute vying for your attention such as Kubernetes, various types of serverless, and more. The problem has become the immense complexity of these solutions — and that doesn’t even begin to cover the need to integrate client-side applications into the mix. WebAssembly is enabling something special, and that is the ability to have reusable modules of code that can be run anywhere, and which can be composed to build powerful software with less complexity.

Let’s cover the basics of WebAssembly; it’s a bytecode format that can be a compilation target for many languages. This simply means that when writing code with Rust, C++, Swift, and more, you can target WebAssembly instead of the executable binary or static library that’s normally produced. The resulting module is language-agnostic and can be executed in a variety of environments. WebAssembly modules are completely sandboxed when they run, meaning that third-party or even potentially unsafe code is less terrifying than your average dependency from NPM or GitHub. It even means that when a WebAssembly module crashes, it doesn’t affect anything outside of its sandbox. WebAssembly can achieve near-native performance (by that I mean faster than JavaScript), and there are a number of different runtime environments both inside and outside the browser to choose from.

Several things differentiate these modules from other code libraries. WebAssembly modules are loaded at runtime, which allows your application to choose when and how a module should be loaded. It also means that you can hot-swap modules without terminating the process or re-compiling your code. This can be quite beneficial when rolling out new versions of your code, as it increases performance and makes deployments faster. These modules are also platform and architecture-independent, meaning you don’t need to create versions for Mac, Windows, Linux, and the various processor architectures they support. The WebAssembly runtime will run natively on those platforms and execute the module no matter how it was produced.

One of the things that gets me most excited about WebAssembly is the ability to share code between client and server. You can imagine building code that not only shares types, but also the business logic associated with it. WebAssembly allows you to write something like an authentication module once, and then run it on your server, in your web app, and in your native mobile and desktop clients. That is not impossible with traditional methods today, but WebAssembly makes it almost trivial. This kind of practice promotes good code encapsulation, sane abstractions, and overall good code design.

Another compelling aspect about WebAssembly modules is the ability to compose polyglot applications easily. Today, it requires a fair amount of engineering work to build systems that interoperate between languages. The microservice pattern incorporates this but often requires writing underlying libraries and shims to make it scalable and intuitive for developers to adopt, not to mention dealing with the potentially volatile network. WebAssembly modules are language-agnostic once compiled, so running a module compiled from Rust alongside one compiled from Swift in the same process is not only possible but straightforward. I can envision a future where a SaaS vendor distributes its API libraries using a set of WebAssembly modules instead of libraries written in Go, Rust, NodeJS, Ruby, etc.

One last aspect of WebAssembly that I have begun to explore is the ability to dynamically decompose an application and have it run across multiple layers of the network. Imagine writing a set of modules that are bundled together into one application, and upon being deployed, begins executing across your centralized cloud environment, an edge network, and your users’ devices, all without you needing to choose what runs at each level. I can envision an application that intelligently sends certain modules to your CDN to be executed in the cloudless than 50ms of latency away from your user, and even some modules that get downloaded to the user’s browser to be executed right on the page. These are some of the incredibly exciting opportunities available to us if we adopt the WebAssembly module as the de facto unit of compute.

Atmo is part of Suborbital, which is a family of open source projects dedicated to helping developers build powerful cloud native applications using WebAssembly. If you’re interested in taking advantage of what WebAssembly has to offer or want to help tackle these very compelling problems, I hope you’ll come to check it out!