Skip to main content

What is the WebAssembly Component Model

Frequently Changing Subject Matter

The WebAssembly component model is changing rapidly, sometimes even daily. This section is under active development and we will strive to keep it up to date as we can.

As an industry, we've tried building components and component frameworks countless times before. We tried COM (Component Object Model) on Windows, which was a binary standard for components that only worked on windows. There was CORBA, EJB, OSGi, and countless others. Each of these frameworks tried to solve the problem of creating reusable units of deployment that could be composed into larger systems. Sadly, none of these ended up being portable, and none of them ended up being particularly easy to use. Further, none of them imposed any constraints on the components themselves, allowing the components to be as tightly coupled to the OS and CPU architecture as they wanted.

"Constraints Liberate, Liberties Constrain" - Runar Bjarnason

The Wasm component model aims to succeed where previous attempts did not.

What is the Component Model?

The WebAssembly (Wasm) Component Model is the realization of a vision of a software ecosystem that is not just based around a portable unit of compute, but something entirely new – composable, interoperable, and platform-independent modules. The component model underpins server-side WASI standards; a common framework for building Wasm projects for more than just browser use cases (whether that’s in the data center, in multiple cloud environments or on devices at the edge).

WASI, and the component model, allow us to split applications into their component parts to remove heavy non-functional requirements (so you’re only writing the right code), which creates tiny, lightweight, highly portable and composable, sandboxed apps that run anywhere.

Wasm runs wherever there's a WebAssembly host runtime - it’s a truly portable compilation target. Imagine a video game that could run on all handheld devices, all PCs, and all consoles without requiring different code. That’s the promise of Wasm.

The WebAssembly application platform we work on is wasmCloud, the CNCF sandbox project (Cosmonic is a core contributor and maintainer). It builds on several other CNCF projects like NATS for a flat, self-healing network topology that makes it really easy for us to distribute Wasm modules across an entire lattice. This means we can write one thing that runs really well in lots of places. Even better, without any code change or redeployment, we can run it right next to my users or their data.

What separates the component model from every prior attempt at building composable applications is two things: constraints and portability.

Both of these benefits come from WebAssembly itself.

A WebAssembly component is a high-level container that can hold one or more WebAssembly modules. These modules are what you might be familiar with if you've been using WebAssembly prior to the component model. While modules and components are code, an instance represents a component or module bound to a block of linear memory. An instance satisfies the imports of a component or module.

Writing a Wasm component should be pretty simple. All we should care about is the functional logic of our code. This is what exemplifies building features faster with Wasm components. Because we work with a high level interface, we only write the call that we need to make. The other powerful benefit is we can treat other components as libraries to build the one component.

Most importantly, it doesn't matter if it's written in Rust or Go or JavaScript, it should be the best and right component for the job. All we need to do is to link these components together and we can start building.