WebAssembly (Wasm) began its journey in the web browser. However, it has since expanded, becoming a sought-after technology for server-side environments, Internet of Things (IoT) systems, and synchronous plugins. With this kind of horizontal expansion, even reaching into multi-tenanted cloud environments, it is clear that Wasm has some desirable attributes. One additional innovation, on the Wasm side, elevates the technology beyond just being desirable. Wasm has the potential to change the game for software developers, revolutionizing the landscape of software development.
What is this new thing that makes Wasm so exciting and special? It’s a technology that hides behind a deceptively boring name: The WebAssembly Component Model.
Before diving into the Component Model, though, let’s trace Wasm’s journey from the web browser to the cloud.
Why Wasm Moved Beyond the Web Browser
The web browser environment (for which Wasm was initially designed) does carry forward some constraints that any deliberately interoperable system (Wasm) must abide by:
Security: The web browser routinely runs code from unknown and untrusted sources. As we click around on the internet, we rely on the web browser to protect us from bad actors and buggy code. In the same vein, Wasm must be highly secure.
Portability: Web browsers run natively on all major operating systems and various system architectures. Wasm must not require that an application be compiled to a specific OS or architecture but must support running on many (ideally all) platforms without compromising performance. Wasm must ensure users have a smooth and efficient experience regardless of where the application runs.
Performance: As we browse the web, we grow impatient, waiting for things to load. Just a few extra moments can give us the feeling that our expected digital dopamine isn’t arriving on schedule. At this point, we often close that tab or move on, clicking, swiping, and liking something else. Wasm must always load and execute immediately to ensure that a user’s interest is retained.
In addition to the three constraints above, a fourth—highly audacious constraint— remains. A way in which all of the disparate language communities (each with its timelines, processes, and prioritizations) can adopt Wasm into their build and runtime toolchains. Optimally, as soon as it is practicably possible.
By rights, Wasm should have failed simply because that fourth item mentioned above could easily be considered unrealistic (in the real world). Yet, against the odds, language communities began supporting Wasm. First, C and C++ gained support (from the Wasm creators themselves), as did the burgeoning Rust programming language. That very well may have been the stopping point. But it was not. Language after language has begun adding support. Python, Ruby, Swift, the .NET languages, Go, Zig… the list started growing and continues to grow. Even wholly new projects (like the functional programming language Grain, which compiles exclusively to Wasm) are building their community and undergoing ongoing development in the Wasm space.
With this level of language support, Wasm consistently increases its foothold as a promising tool. Wasm’s security, portability, and performance virtues are making savvy developers outside of the web browser world begin to notice. This foothold gets stronger whilst stories of companies like BBC and Disney (using Wasm in their embedded streamed video apps) appear, other parts of the web like Samsung documentation pages go on to explain “WebAssembly and its application in Samsung Smart TVs”. Cloud innovators such as Fastly, Fermyon, and Microsoft continue to enhance Wasm tooling and frameworks, integrating Wasm seamlessly into cloud and edge computing. Companies like Shopify, Suborbital (now part of F5), and Dylibso making leveraging Wasm as a plugin framework a reality. All roads lead to refining the Wasm application developer experience and simplifying Wasm’s implementation in mainstream products and services. If we boil it down, in every case, the magic formula is the same: Wasm offers a secure, portable environment that performs well across devices. In addition, there is broad support from various language ecosystems.
Detractors might point out that this is mainly overwrought praise for boring features. Sure, it’s fine. One could argue that other solutions just might also be “fine”, right? More to the point, if the ambitions behind Wasm stopped here, then I would have to agree: Wasm is simply a “good enough” technology. But something has been brewing in the standards groups working on Wasm. And this “something” boosts Wasm from fine to redefining.
The Component Model is the Future
Here’s an intriguing question: If languages such as Rust can compile to Wasm and Python can operate within Wasm, could there be an architecture to build interoperable Wasm libraries, applications, and environments? If the answer is affirmative, we might be on the verge of realizing a goal that has largely eluded the programming world:
creating libraries (programs with reusable code) that are universally usable, regardless of their source language.
The audacious goal of the Wasm project was that, in theory, any language should be able to run in a Wasm runtime. And the surprising fact is that many languages (over two dozen) already can.
In addition, a library can be written in the language best suited for it and then shared to all other languages. For example, a high-performance cryptography library might best be written in Rust, where one could argue that built-in handling of null pointer dereferencing, dangling pointers, and buffer overflows might make Rust the safest tool for that particular task. Another example is that a library related to data processing might better be written in Python, perhaps due to its network effect in this programming genre and Python’s already extensive data processing library ecosystem. Don’t hang your hat on just these conversations. This is but the tip of the iceberg.
The component model enables developers to update specific sections of an application rather than overhauling the entire system. If a security vulnerability emerges in the cryptography component, for instance, only that individual component needs to be upgraded, leaving the rest of the application untouched. Moreover, such updates might be executed in real-time, eliminating the need for a full system shutdown, rebuild, and deployment. This approach could foster more agile application iterations. Furthermore, data storage backends can be interchanged seamlessly without modifying the broader application’s code. Implementing specialized tests, collecting metrics, and debugging could be as straightforward as integrating the appropriate intermediary components into the application without altering the existing code.
This approach will seem revolutionary for developers accustomed to regular code rebuilds and redeployments. What’s thrilling is that this technology is already here. Tools like Fermyon Spin and the Bytecode Alliance’s Wasmtime fully support this component model. And with the Component Model being standardized by the respected W3C (the standards body responsible for HTML and CSS), it’s open for anyone to implement. It’s anticipated that the Component Model will be widely adopted in the Wasm ecosystem within a year.