WebAssembly (abbreviated Wasm) is a technology that has been packed with potential since its inception, floated as everything from the “JavaScript killer” to the “next frontier of cloud computing”. In a world undergoing platform shifts to the cloud and the edge, Wasm has rapidly begun to expand beyond its role as the fourth official language standard of the web, redefining how we think about application development and bringing us closer to the promised land of “write once, run anywhere”. 

We’ve witnessed applications of Wasm graduate over the last few years from hopeful demos to full-fledged implementations powering the products of multi-billion dollar technology giants. However, we’ve learned through our conversations with leaders across the Wasm community that there are still open debates over how best to achieve the expansive vision that many have for the technology’s future.

Nevertheless, at Sapphire, we couldn’t be more excited by the rapid development surrounding the Wasm landscape and the new possibilities Wasm has begun to unlock for the broader world of computing. In this article, we will explore what Wasm is, why it matters, how it is used today, and what we are looking forward to for the ecosystem to flourish. We won’t be discussing the history of Wasm, but we recommend taking a look at Lin Clark’s fantastic series of articles here if you’re curious as to how we got to where we are today.

What is Wasm?

WebAssembly has evolved to become a bit of a misnomer in two ways:

1. It’s Not Quite Assembly: Wasm is a binary instruction format and an assembly-like language that is not quite as low-level as Assembly (i.e., machine code), but is definitely closer to being machine-readable than human-readable (i.e., bytecode). Developers don’t write Wasm themselves; instead, they can compile their code to Wasm using their choice of several languages (e.g., C, C++, Rust, Go, etc.).
2. It’s No Longer Just the Web: While Wasm was originally designed as a compilation target for the web, its reach hasn’t stopped there. Today, using Wasm-compatible runtimes, Wasm files can be executed both client-side and server-side, extending the breadth of Wasm’s use cases beyond the browser – examples of which we’ll explore further below.

Why does Wasm matter?

Wasm has a few key high-level goals and advantages that make it compelling:

Wasm is portable.
While Wasm was originally designed for the web and all major browsers offer support for Wasm today, it has also been designed to target virtual machines whose instructions are separately translated by the physical machine into machine code. This means that Wasm binaries can ultimately be run on a variety of operating systems and chip architectures – whether it’s in the browser of a laptop running an x86 chip, on a server on-prem or in the cloud, on mobile devices, IoT devices, etc.

Wasm is polyglot.
Because Wasm is a compilation target, the specific language used to program the module matters less than whether there is support available for compiling that language to Wasm. Developers therefore have flexibility in using multiple languages (e.g., C, C++, Rust, etc.) to build binaries and take advantage of the benefits Wasm offers. This also implies that components and libraries written in different languages can be combined to support a single application, assuming they are all compiled to Wasm.

Wasm is fast & efficient.
Because Wasm is a low-level binary instruction format, fewer operations are required to translate Wasm into optimized machine code. Compare this, for example, to Javascript running in the browser (Lin Clark wrote a great walkthrough of this here). Javascript is an interpreted language that must be compiled at runtime with just-in-time (JIT) compilation and must go through the steps of fetching, parsing, compiling, optimizing, de-optimizing, executing (finally!), and garbage collection.

While JavaScript has to be parsed and converted to bytecode, Wasm is already natively bytecode, circumventing parsing entirely. Wasm is also statically typed, meaning most optimizations are completed upon its initial compilation. On the other hand, JavaScript is dynamically typed, requiring optimization and re-optimization at runtime which together lead to less predictable performance.

These advantages carry through beyond the browser as well, particularly with ephemeral workloads for which the size efficiency of Wasm modules is especially impactful. A well-documented problem with serverless platforms today is the slow cold start. While serverless functions save developers time from having to manage the backend infrastructure and resource allocation, if that function is invoked in a cold state, new resources must be spun up, adding additional latency to total execution time. Because Wasm modules are extremely lightweight with overhead that mimics a library call, startup times can be significantly reduced (down to milliseconds).

Wasm is deny-by-default.
Wasm uses a deny-by-default security model, executing within a sandboxed environment with no initial visibility to the host runtime. This means that access to system resources (e.g., file systems, hardware, etc.) is restricted and otherwise must be explicitly and granularly granted. Wasm, therefore, limits the attack surface and enables multi-tenant environments in which untrusted code can be executed with greater confidence. This security model is a key enabler allowing developers to extend existing applications with plugins and user-submitted code, a use case we’ll explore further below. 

How is Wasm used today?

Client-side use cases

Polyglot language support in-browser
Languages used to develop client-side applications have historically been limited, with most modern web applications today being built with Javascript. Browser and framework support for Wasm have begun opening the floodgates, making it more accessible for developers to compile and execute other popular languages in-browser. Now, developers have the option to run the likes of C, C++, Rust, and Go among others directly inside the browser. Additionally, emerging system languages like Zig have added first-class support for Wasm while others specifically designed from Wasm have also emerged including AssemblyScript, Grain, and Motoko.

High performance web applications
We’ve seen companies use Wasm to significantly improve the performance of their web applications. For example, Figma, a browser-based collaborative interface design tool, built its rendering engine using C++, initially cross-compiling its code to a subset of Javascript known as asm.js which preceded Wasm but ultimately faced limitations in optimization inherent to Javascript. After switching to Wasm, Figma saw 3x faster load times, regardless of the size of the document that was being loaded.

Multi-billion dollar companies have already embraced Wasm in and around their client-side product offerings. Adobe has done this with Photoshop and Autodesk with AutoCAD, reusing existing codebases to port entire desktop applications to the web with Wasm. Other fun examples include ports of full-fledged video games and projects like Doom3 and Angrybots running completely within the browser, with Unity explicitly having switched the compilation target of their WebGL build to Wasm.

Beyond ports, we’re seeing companies leverage Wasm in building net new features that would have historically been constrained by performance limitations. A few examples include Runway, a next-generation content creation suite using Wasm to power its video codec and media manipulation, and StackBlitz, using Wasm to power its web IDE in order to achieve security and performance advantages over more traditional online IDEs that stream from remote servers.

In-browser databases & analytics
We’ve begun to see databases emerge that are taking advantage of the execution performance Wasm enables to bring historically server-side analytical workloads closer to where the data lives. Examples here include DuckDB-Wasm, which is using Wasm to power an in-process analytical SQL database for the browser, and SQL.js, which allows developers to create and query SQLite databases entirely in the browser.

Wasm beyond the browser: WASI

Given that Wasm modules by default can’t make system calls without being explicitly granted access, the level of functionality that developers can achieve using barebones Wasm is limited. In the examples above, the browser itself facilitates access to system resources (e.g., filesystems, I/O, clocks, global variables, etc.) on behalf of the Wasm module. However, what happens when we need to use Wasm outside the browser? 

In practice, runtime implementations can vary widely in how they provide access to system resources. This is where the WebAssembly Systems Interface (WASI) comes in. A W3C project, WASI is a vendor-neutral, modular collection of standardized APIs that, as indicated by the name, acts as an interface between Wasm modules and the operating system, facilitating communication with the host runtime and the use of select system resources in a consistent manner.

Naturally, WASI is one of the critical enablers expanding the scope of what is possible with Wasm, including server-side applications like the ones below.

Server-side use cases

While there have been plenty of examples demonstrating the benefits of Wasm on the client-side, we’re particularly excited by the implications of Wasm with each of its design principles (speed, security, and portability) enabling the next wave of server-side workloads.

Serverless computing
Given their highly optimized cold starts, Wasm runtimes like WasmEdge are well-suited to power a next-generation of serverless platforms. Companies like SecondState, Cloudflare, Netlify, and Vercel all support deploying WebAssembly functions via their edge runtimes. Others like Grafbase are using Wasm to enable developers to write and deploy GraphQL resolvers at the edge in the language of their choice. Meanwhile, Fermyon offers a self-service FaaS-like development platform for composing and running cloud-based applications with Wasm.

Data analytics & machine learning at the edge
Wasm’s efficiency and portability make it uniquely suited for supporting machine learning workloads at the edge, deployed to devices that vary greatly in terms of form factor and computational power. We believe that real-time ML use cases will push compute closer and closer to where the data is generated, whether running on the network edge (e.g. CDNs) or device edge (e.g. IoT). wasi-nn (neural network) is an API spec aiming to connect server-side Wasm programs with popular ML frameworks (e.g. Tensorflow, PyTorch, OpenVINO) running on the host. Companies leveraging Wasm for ML use cases today include Edge Impulse which offers a low-code development platform to design and deploy TinyML models into Wasm modules running on embedded devices, and Hammer of the Gods which enables developers to create ultra-portable containers for running ML workloads at the edge using Rust and Wasm via its open-source project, Rune.

Plugins and extensions
The multi-language support and sandboxed isolation techniques of Wasm make it a strong candidate for product owners looking to provide an extensibility model and the ability to execute third-party (trusted or not) code atop existing applications. For example, Shopify is using WebAssembly behind its Shopify Scripts framework, providing merchants with the ability to customize performance-sensitive aspects of the customer experience (e.g., carts, checkout) in a more efficient manner. Suborbital provides an extension engine that enables SaaS providers to run ‘end-user developer’ supplied code safely and independently. Dynaboard is enabling developers to run user-provided code both client-side and server-side on top of their low-code web app development platform.

SingleStore and ScyllaDB have begun leveraging Wasm to extend their databases with user-defined function (UDF) engines, allowing developers to re-use existing libraries and move computation into the database itself (e.g., circumventing the need to export data to another application for processing).

Meanwhile, RedPanda and Infinyon allow users to perform inline transformations on streaming data in real-time using Wasm.  The proxy world is starting to embrace Wasm as well, and service mesh providers such as Tetrate (a Sapphire Portfolio company) are developing utilities like func-e to help teams quickly scaffold Wasm modules that extend open-source Envoy.

Profian is the custodian of Enarx, an open-source project which uses the Wasmtime runtime to execute Wasm binaries inside of trusted execution environments (TEEs) – another use case in which Wasm’s hardware portability is key. While Wasm’s security model protects hosts from untrusted code, Profian flips this benefit inside-out, using Wasm binaries inside of TEEs to instead protect applications from untrusted hosts. This allows organizations to deploy their sensitive applications and data to the cloud or on-prem with cryptographic assurance.

Web3 application development & smart contract execution
Wasm is a natural fit for crypto-centric use cases given that 1) Wasm’s portability enables reliability across networks of nodes running diverse sets of hardware, and 2) Wasm’s efficiency limits state bloat while maintaining performance, translating to broader efficiencies across those networks.

Ewasm is a key example, and seen as a critical component of the Phase 2 upgrade of Ethereum. Ewasm stands to replace the Ethereum Virtual Machine (EVM) which powers transactions and maintains Ethereum’s network state today but hasn’t been optimized for different hardware platforms and therefore is inefficient. Ewasm (along with sharding and the shift to proof-of-stake) stands to improve overall network performance and provide a more extensible substrate, expanding language support beyond Solidity for developers looking to build decentralized applications.

Wasm is also being used to power compute across other networks and interoperable blockchains. For example, Parity is the developer of Substrate, an open-source framework that uses Wasm to serve as the backbone of the Polkadot ecosystem. Meanwhile, CosmWasm is a multi-chain smart contract platform built for the Cosmos ecosystem that runs Wasm bytecode. Fluence Labs offers Marine, a general purpose Wasm runtime that, combined with their purpose-built programming language Aqua, enables decentralized applications and protocols to run on their peer-to-peer network. Other protocols that leverage Wasm today include NEAR, Dfinity, EOS, & more.

The Wasm Application & Infrastructure Landscape

We’ve laid out just some of the companies and organizations that are either 1) using Wasm today to power their own products and platforms or 2) providing the foundational tooling and infrastructure needed to empower developers to build with Wasm themselves:

Closing Thoughts

The Future of Wasm

While we see a number of impactful, real-world use cases being adopted by startups and tech titans alike, several of the ecosystem’s critical advancements have only developed in the last few years. Today, many of the incremental benefits of Wasm can often be outweighed by the effort necessary to effectively use a complex low-level technology with a still-maturing toolchain.

There are four areas that we believe can play key roles in driving the future adoption of Wasm:

• A Seamless Developer Experience: Historically, the effort necessary for developers to leverage Wasm at an enterprise level has been prohibitive. The Wasm developer experience is still not frictionless (e.g., debugging Wasm remains notoriously difficult), and there’s plenty of room for better tooling across the development lifecycle, both in compiling to Wasm and in leveraging Wasm in a practical way. The reality is that most developers don’t have expertise with low-level languages and technologies, so advancing usability through abstraction is incredibly important to fuel adoption by a wider audience. We’ve begun to see the first wave of companies explicitly dedicated to equipping developers with these tools including Fermyon, Second State, Suborbital, Wasmer and Cosmonic.
• The Continued Advancement of Standards: While the community is not without some fragmentation (e.g. see AssemblyScript’s decision to drop WASI support), we are generally excited by the collaborative nature with which foundational Wasm standards are being specified and advanced. In addition to a burgeoning startup ecosystem, tech giants like Microsoft, Amazon, Google, Fastly, Cloudflare, Mozilla, etc. have begun to recognize Wasm binaries as an effective substrate for powering the next-generation of cloud workloads, and they are actively contributing to standards bodies and non-profit organizations like the W3C and the Bytecode Alliance to propel this community forward. The CNCF is also playing an important role, accepting wasmCloud (orchestration) and WasmEdge (runtime) as sandbox projects. There is still important work to be done; basics like documentation, and in-flight PRs for key features like garbage collection, native DOM access, sockets, threads, the Component Model, etc. must continue to progress in order to make Wasm more applicable across a wider array of targets and applicable to a broader set of use cases.
• Language Support: Though one of the most commonly touted benefits of Wasm is multi-language support, the reality of the current state of support is somewhere in between. Languages like C++, Go (including TinyGo), and Rust have embraced Wasm, but some of the most common languages such as Python, Java and PHP are still inching towards first-class citizen support. To truly achieve mainstream adoption, Wasm support must continue extending beyond some of the more complex (and at times esoteric) languages like C++ and Rust and toward the most widely adopted languages. For those interested in tracking progress on this front, the Fermyon team has done a great job compiling a matrix that tracks Wasm support across RedMonk’s top 20 programming languages. 
• Awareness, Evangelism, & Community:  Just as we saw in the case of containers and orchestration engines like Kubernetes, developer adoption of Wasm can be pushed further by evangelists and a broader, established community of advocates. Organizations like the Cloud Native Computing Foundation (CNCF) and the Bytecode Alliance have been at the forefront of engaging developers to promote participation in Wasm-related projects, events, and initiatives. Beyond the developer audience, awareness among other stakeholders of Wasm can be driven by articulating second-order value propositions such as the potential for cost savings attributable to the use of Wasm in cloud and serverless environments.

Will Wasm replace containers?
Over time, we believe Wasm runtimes will act as a legitimate alternative to containerd, microVMs (Firecracker), and other popular container constructs – particularly as standards such as WASI are further extended. This is not to suggest that Wasm will wholesale replace containers; they will exist side-by-side for the foreseeable future, with the decision to leverage each being driven by the characteristics of a given workload.

Docker-style containers provided a significant improvement over more traditional hypervisor-based VMs, and Wasm has been able to take many of these same efficiencies to the “next level”. With their sub-millisecond cold starts, Wasm containers are well-suited for shorter-lived serverless and edge workloads (in addition to existing client-side use cases). Meanwhile, traditional Docker-style workloads are a strong fit for longer-running services (e.g., a caching server) that require heavy I/O or need access to network sockets.

We’re eager to see how orchestration engines like Kubernetes approach integrating with Wasm over time. Though early, projects and extensions like Krustlet (alternative to kubelet agent), runwasi, Containerd Wasm Shims, and crun’s Wasm handler are aiming to elevate Wasm to a first-class citizen within container environments, presenting it as a new runtime class that can be scheduled and managed accordingly by K8s.

Who stands to win?
Cloud service providers and serverless platforms are the obvious candidates here. But at Sapphire, what really has us keeping a close eye on the activity materializing in the world of Wasm is the rare opportunity for a new ecosystem to blossom.

With any emerging technology comes the need to make it usable for mainstream adoption. We’ve begun to see real signals of this take shape with the examples above. However, while the standards being advanced and the frameworks and runtimes being developed today have laid the groundwork for realizing Wasm’s potential, much remains to be done. From Wasm-centric platforms for application development and developer productivity to observability instrumentation and security solutions, we’re excited to support those building the infrastructure and tooling needed to unlock the advantages of Wasm for everyone, from the individual developer to the global enterprise.

If you’re contributing to the Wasm ecosystem or are using Wasm to power your infrastructure, please reach out to [email protected], [email protected] or [email protected] – we’d love to hear from you!

Special thanks to Michael Yuan, Matt Butcher, Liam Randall, Connor Hicks, and Alexander Gallego for their invaluable perspectives and feedback.