WebAssembly is a binary instruction format for a stack-based virtual machine. It is designed as a portable compilation target for programming languages, enabling server & client applications to be deployed on the web.
You might have seen the above definition of WebAssembly (Wasm) after a quick Google search. That’s a lot to digest. To grossly oversimplify, Wasm is a compilation target. You can take code written in ~30 languages, compile it to a .wasm file, and then execute that file in many environments - namely in a browser and/or on a server. Wasm files contain binary instructions that a virtual machine can read, and because Wasm targets a virtual machine, it works on many chip architectures. It targets the lowest common denominator of popular hardware, a stack machine, which is what sets it apart from other targets that produce binary code.
To clarify, you do not write WebAssembly - you compile one of ~30 languages to WebAssembly, using a tool specific to that language to compile it, and it produces Wasm code. The most popular languages that target Wasm are C, C++ & Rust right now (namely because they manage memory themselves and don’t need a Garbage Collector). Support for the Go, Python & JavaScript ecosystems is growing pretty quickly as well.
One more thing to note: Wasm was originally built for the browser, but as the technology matures, we are seeing more and more use cases for it on the server-side, some of which are explored in this post.
How WebAssembly works - courtesy of @ Alex
💡 You write code in chosen lang (often C/C++/Rust) → you use a specific compiler for that language → this creates a .wasm file which contains lower-level bytecode → this/these files are executed via a browser's runtime
So, Wasm lets you write code in the language of your choice and run it anywhere. What makes it interesting?
On the server, Wasm can achieve 10-100x faster cold start times vs Docker Containers, because it does not need to create an OS Process for every container. In the browser, decoding Wasm is faster than parsing, interpreting & optimizing Javascript, so your Wasm code begins executing faster in the browser than JavaScript does.
There is some debate around the specifics of Wasm's performance, but where it can excel is in allowing users to offload computationally intensive parts of their applications to lower-level languages.
💡 A lot of the performance benefits of Wasm come from the fact that it (it being Wasm code) is built to be as close to native machine code as possible
❓ While some companies have seen great success using WebAssembly, there is a lot of work to be done still. The ZapLib team wrote a great piece on their experience with Wasm & Rust performance here
Wasm binaries are small in size and therefore use only a small amount of bandwidth, typically taking less time to transfer over a network than, for example, cross-compiled JavaScript in the browser. See Figma’s piece on this.
Any Wasm runtime can run any Wasm code (though not all runtimes support all Wasm extensions yet, ie different WASI interface types). The majority of browsers support WebAssembly, and there are many runtimes on the server-side (WasmEdge, Wasmtime etc) that execute Wasm code. Given such broad support for Wasm in the browser & on servers (and in turn, on hardware), it is portable. It is quite universal too - ~30 languages compile to or execute in it (C, C++, Rust, Python, Go, AssemblyScript, JavaScript, and many more).
The two goals of WebAssembly’s security model are: (1) to protect users from buggy and/or malicious modules, (2) to give developers the primitives they need to develop safe applications. To that extent, Wasm’s scope is limited. Code running in a Wasm runtime is memory sandboxed and capability constrained.
The above points make it interesting for both client and server applications. On the client, there is a world where (in part) because of Wasm, the browser finally becomes the default operating system where all applications run. On the server, Wasm has the possibility to become the next default container system. What Docker did to virtual machines, Wasm will do to Docker. As Matt Butcher at Fermyon puts it:
If VMs are the heavyweight class of cloud computing, and containers are the middleweight class, WebAssembly is the perfect fit for a lightweight class.
Wasm will give us fast & secure client & server applications. What are some specific use cases?
As per the Figma use case, with Wasm, one can take performance/computationally-intensive parts of their application written in JavaScript, and swap that JavaScript out with a more performant language, such as Rust/C/C++. But this is not always the case. Again read the ZapLib post-mortem for a detailed overview of Wasm performance.
Write once, run everywhere - WebAssembly hopes to fulfil this dream of a term, originally coined by Sun Microsystems, pertaining to Java. This is not a simple feat in practice, but Wasm definitely makes it easier to bring applications to the Web (and other platforms) that were previously native. Good examples of this are Photoshop and Autodesk Web.
💡 If I were starting a company and looking for ideas, I’d be thinking heavily about what applications are (1) desktop native, (2) slow, and (3) If they are in the browser, are often still slow. The major one for me is spreadsheets.
Wasm is great for executing untrusted code in an isolated sandbox. Once most platforms get to scale, they end up building plugin systems, where they enable end-users to build custom software that interface with their platform. By using Wasm for this plugin system, platforms can let their users build plugins in any language, and not worry as much about the security risks of letting users execute untrusted code, because that code is sandboxed. All of the other benefits of Wasm come into play here too: speed, small binaries, and fast loading. Every plugin system wants to be high-performance, secure, and easy to use by default, and Wasm helps that become a reality.
🧠 As Bailey Hayes at SingleStore put it in a recent talk at Kubecon, a plugin can be much more than just an application. One could treat any smart contract as a plugin for a given blockchain, or any serverless function as a plugin. When one zooms out, many technologies can be treated like plugins.
As mentioned, Wasm has a constrained security model, it is cross-OS, has fast cold-start times, has great performance, does not need to create a new OS Process for every container, and has a very small footprint. These are all attractive traits for a new type of container system that could replace Docker. As Solomon Hykes famously tweeted, WASI is the missing link to really drive this new container system forward. We’ll dive deeper into WASI later.
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!
There will be a package registry & manager for WebAssembly. WAPM were the first to try this (that I’m aware of), and I know there are some other projects in the works that we’ll hear more about soon. WebAssemblyHub looks interesting but I have not spent much time on it yet. Once WASI & The Component Model are ubiquitous, there will be many compelling reasons as to why one would use a Wasm package manager. More on that later.
In the browser, WebAssembly could be great for the same reasons it is great for performance-intensive web applications: make them run performantly on the web. As per the WebAssembly Docs, examples included lightweight games that need to start quickly, asset-heavy AAA games, and peer-to-peer games.
Also according to the WebAssembly docs, it could be used on the server to create a game distribution service that makes games portable and secure. Admittedly, I have not thought about what this would look like in practice.
🔗 Check out D3Wasm for an example of Doom 3 running in a browser!
People have been talking about Wasm as an alternative to the EVM, such as Parity in this blog post. The Parity Ethereum Client runs Wasm bytecode in Wasmi, which enables the Wasm code to access and interact with the blockchain. Another good example is ewasm, which is currently being researched as a replacement for EVM1 (source). It aims to let developers interact with the Ethereum blockchain using WebAssembly, and thus, support more languages.
This quote from Ake Gaviar’s piece on WebAssembly & blockchains sums up how Wasm might work with blockchains in the future:
Our browser loads Wasm code into its virtual machine and runs it. You know what else does that? A decentralized world computer like Ethereum.
💡 Is there a world where Wasm is the default compilation target for all of the major public blockchains? What does this mean for cross-chain development? What does this mean for layer 2 blockchains, if anything? If anybody has insight here, I’d love to learn more.
A use case analogous to plugin systems is server-side compute of untrusted code. Many platforms end up exposing their own system for letting end-users write code on top of their platform, for example, Airtable Scripts. Using Wasm, a platform like Airtable could let its users write functions in the Airtable Scripting platform written in multiple languages. The team at Suborbital are aiming to make this simple for any company to implement.
💡 I firmly believe that this is the future of low-code platforms, enterprise software, and a whole host of other industries. Imagine a world where your user could extend your software in any way they need, by clicking a button within your application that fires up a code editor (or perhaps an IFTT editor similar to n8n or Zapier?) to let them get to work on building new functionality. There’s a lot to build here beyond the editor - every app will likely have a marketplace of common snippets/executions, pre-built integrations, and more.
❓ Recently, Cloudflare announced Workers for Platforms, a new service on top of Workers for exactly this use case. Will vertical companies start to spring up offering a similar use case?
Serverless functions are the perfect use case for WebAssembly - Wasm’s sandboxing, performance, fast startup times, and language support make it the perfect technology for running serverless functions. Cloudflare Workers supports it, Second State’s FaaS is built around it, Deno Deploy supports it, and the bigger cloud platforms are starting to follow suit. I'm also keeping an eye on Spin.
RedPanda uses a Wasm engine for inline data transformations, as does Infinyon. However, this is just one example of how Wasm can be used to execute code inline. Envoy lets you write inline filters using Wasm, for example. All of these inline computations can theoretically be written in any Wasm-supported language, and furthermore, they all look like plugins interacting with some underlying infrastructure.
As IoT/connected devices that work in real-time become more and more popular, being able to perform real-time machine learning will become crucial. Runtimes like WasmEdge make this possible. This blog post walks through running TensorFlow Lite on WasmEdge.
There are a lot of similarities that can be drawn between the JVM (Java Virtual Machine) and WebAssembly. From my understanding, the JVM is at the core of the Write Once, Run Anywhere paradigm that we alluded to earlier. Write Java code on one machine, and run it on any other machine running the JVM. As per this FreeCodeCamp article:
Similar to virtual machines, the JVM creates an isolated space on a host machine. This space can be used to execute Java programs irrespective of the platform or operating system of the machine.
Wasm has a similar promise to the JVM and depending on where on the web you land, there are different opinions on Wasm vs. the JVM. There are a few key differences that make Wasm stand out:
Lots of companies are using Wasm in production, the below are just a couple of the ones that I’ve been tracking.
Dynaboard uses WebAssembly for its plugin system. All user-supplied code runs in a Wasm sandbox. They chose WebAssembly over a few other options (ShadowRealms, Inline Frames on a separate host with native JS eval(), a Custom DSL) because it is generally more performant, makes it simple to support multiple languages, and is easier to implement.
Grafbase deploys your GraphQL API to the edge via Wasm to achieve globally fast performance without cold starts. Soon, they'll offer the ability to write custom GraphQL resolvers using JavaScript or any language that compiles Wasm.
Suborbital’s focus is all about being able to run untrusted code. Using Suborbital, any platform can let its users execute untrusted code that interacts directly with the platform, without having to worry about setting up any infrastructure, security, or performance. In many ways, it replaces the need for an application to have webhooks.
Figma’s rendering engine is written in C++ and is compiled to WebAssembly to run in the browser. This way, the performance-intensive parts of their applications run in C++, allowing the Figma browser app to perform/feel like a native application. They also use WebAssembly to power their plugin system.
Shopify uses WebAssembly to execute untrusted code in performance-sensitive contexts (e.g. Checkout). This means that they can extend Shopify through Wasm in a safe and performant way.
SecondState is building an edge-native PaaS powered by WasmEdge, their Wasm runtime built for cloud-native, edge, and decentralized applications. Alongside multiple languages, It runs JavaScript, including 3rd party ES6, CJS, and NPM modules.
Fermyon is also building an edge-native PaaS powered by WebAssembly, and generally, an ecosystem of tools that make for a best-in-class developer experience. I’m personally most excited about Spin, their framework for building and running fast, secure, and composable microservices.
Cosmonic is working on a platform for building and deploying secure, portable, scalable services across clouds, edges, browsers, and everything in between. They're the creators of wasmCloud, a WebAssembly Application Framework that combines the properties of WebAssembly with pluggable components. With this, developers can write their business logic and mount disparate capabilities across edges, browsers, or clouds.
Stackblitz uses WebAssembly and WebContainers to power an entire development environment in the browser. WebContainers allow them to spin up full Node.js (and other) environments in the browser. This is particularly exciting because most existing cloud dev environments (that I know of) run their environments on a remote server and stream the results to the client.
Hopefully by now, I’ve convinced you that WebAssembly is a cool technology that will have a meaningful impact on how we create software. I believe this is true, but that we’re ultimately still a while away from this becoming a reality. The folks at the Bytecode alliance are working hard to make WebAssembly as well-rounded as it needs to be to deliver on everything we’ve talked about so far. Below, I’ve listed a couple of important proposals coming down the line. I’d love to write about them in detail, but for the sake of brevity, I’ll leave that to others who have already done a great job here!
For WebAssembly to thrive outside of the browser, it needs a standardized operating system to interface with whenever it runs outside of the browser, and all of the languages that run in WebAssembly need a standard set of system calls (I/O interfaces) to communicate with that OS. This is what WASI (WebAssembly System Interface) is - it acts as a virtual operating system, making it possible to run the same Wasm binary across different operating systems, without compromising the effectiveness of the WebAssembly sandbox. WASI is made up of a collection of standardized APIs. One could write an entirely separate piece on WASI, so I won’t cover it in any more detail here. This website gives a great overview of WASI, and this repo tracks all the WASI APIs across three stages: Pre-Proposal, Feature Proposal, and Proposed Spec Text Available.
The WebAssembly component model’s high-level goals are described here. The first listed goal is to:
Define a portable, load- and run-time-efficient binary format for separately-compiled components built from WebAssembly core modules that enable portable, cross-language composition
In simpler terms, the aim of the component model is to eventually create a world where Wasm code can be used like Lego Blocks’. In the same way that developers can use NPM to install packaged JavaScript code, the Wasm component model aims to provide the building blocks to allow Wasm modules to become reusable. The cool thing here is that these Lego Blocks can be written in any language that compiles to Wasm, and in turn, can be imported into any language that compiles to Wasm. You can read more about how WASI works in relation to the component model here.
You can also read about WAGI and WIT if you’re interested in the future of WebAssembly.
WebAssembly is not perfect and does not solve all use cases. There are many issues and things that need to improve in the long-run, such as:
I wouldn’t exactly call any of these technologies direct alternatives to Wasm. All have their use cases and likely will for a long time, but they are the ones that kept popping up as I read this post so I felt it would be amiss not to mention them
I really like WebAssembly. You should also really like WebAssembly. It’s not without its flaws, and for the final time, I will say that some of what I wrote about above is theoretical, but it has the potential to revolutionize how we build applications. In a world where Wasm is ubiquitous (along with proposals such as WASI & The Component Model), applications will be safer, more performant, and extensible. Not just traditional client/server web applications, but IoT, edge, and more. Historically, making things programmable has been a winning strategy (a la Cloudflare with their programmable CDN, AWS with programmable Cloud Infrastructure), and now Wasm makes that possible for a whole host of use cases.
I’ll leave you with some fairly broad predictions. Unfortunately, as much as I am excited about Wasm, I’m not in the weeds every day figuring out how it could be used. If you are, please do share your thoughts!
Most of the relevant links to articles from the above are listed in the wasm-resources repo linked below (please add to it!). You can get a much more detailed overview at awesome-wasm (also linked below).
A curated list of projects, companies, and videos related to WebAssembly to document the interesting things I find as I explore the ecosystem.
😎 Curated list of awesome things regarding WebAssembly (wasm) ecosystem.
There are too many people to thank for reviewing this post & educating me on WebAssembly. Some in particular that helped with incredible feedback: Bailey Hayes, Keith Adams, Luke Wagner, Alex Mackenzie, Audrey Miller, Steve Manuel, Mark Christian.
* denotes a company I'm an investor in
Subscribe to future posts
I've got many more posts in the works. Subscribe to be the first to hear about them.