WebAssembly (Wasm) has revolutionized how we think about portable code, enabling fast, secure, and platform-independent applications running on various devices and environments. It’s an integral part of many software applications and is used by big-name companies like, but not limited to, Adobe, Microsoft, Cloudflare, Docker, Google, Figma, Tesla, Roblox, Snapchat, Pinterest, Visa, Spotify, and Netflix.
The WebAssembly ecosystem spans many projects, including wasmCloud, WasmEdge, and Wasmtime. WebAssembly is steadily reaching new use cases, from WASI-NN, a WebAssembly neural network, to WebAssembly smart contracts like cosmwasm.
In 2024, WebAssembly introduced defining changes like The Component Model and WASI 0.2, spurring a capability boost across the WebAssembly ecosystem. More on this later.
Despite this surge in adoption, the tech community responded with tentative optimism. Articles titled “Maybe WebAssembly Isn’t That Stupid Of An Idea After All” and “WebAssembly Is Still Waiting For Its Moment” made it clear that WebAssembly’s capabilities haven’t entirely caught up to the hype yet.
Keep in mind, the community’s skepticism isn’t unwarranted, especially given the failure of many solutions proposed before WebAssembly’s inception that were supposed to solve the problem WebAssembly was initially designed for: the web’s lack of interoperability, portability, and language-agnosticism (and more, but this is for brevity’s sake).
WebAssembly itself wrestles with issues, such as inconsistent runtime experiences and inefficient management of system resources. Even the CNCF’s State of WebAssembly 2023 report noted that while enthusiasm for WebAssembly increased, the technology faced several challenges.
However, this level of capability and adoption isn’t enough to indicate WebAssembly has “had its moment”, so what is?
Whether Promised or Not, It’s a Problem
There are several reasons why the WebAssembly hype plane experienced some turbulence along the way. While the turbulence critics report are valid concerns for technology as critical and popular as WebAssembly, WebAssembly’s problems are not necessarily isolated to WebAssembly. This is not stated to undermine the pertinence or impact of these critiques, but to highlight the technology’s past and current challenges and acknowledge areas of improvement.
Expectations Rooted in Misconceptions
With all the excitement since WebAssembly’s inception, many promises, predictions, and proposals were made that, while not intentional, either didn’t become reality, were delayed, or took longer than expected to implement. For example, in WebAssembly’s early days, speed was one of the advantages that became synonymous with the technology. WebAssembly was fast. In many ways, this claim was valid. WebAssembly executes as a low-level binary interoperating with JavaScript to speed up computationally intense tasks that JS and its JIT compiler are not optimized for. As WebAssembly garnered more attention, claims escalated from “WebAssembly is faster than JavaScript” to “WebAssembly will replace JavaScript altogether”. However, speed tests soon revealed that WebAssembly had a few troublesome exceptions, such as excessive communication between JavaScript, the host, and WebAssembly. In some cases, WebAssembly even executed slower than JavaScript alone.
The idea that WebAssembly should be leveraged for speed was a common misconception in the early days of the technology. The good news is that WebAssembly’s utility lies in its other strong suits, and the near-native speed, which is partially true, acts as a bonus. Either way, it seems that WebAssembly’s speed, while impressive, may have been misunderstood as a cure-all tonic and therefore serves as an example of how a community may be let down by or misunderstand the purpose of a technology, hindering adoption.
Slow to Feature, Slow to Adoption
The hype around WebAssembly’s speed serves as evidence that often the initial direction for a technology shifts during development. WebAssembly, despite already being a production-worthy tool, is realistically a novel work-in-progress with many features on the way. Features critical to WebAssembly’s wider adoption all developed slower than the community anticipated or hoped. For example, it’s easy to see why there was both frustration and hype around Python compiling to WebAssembly, which depended on the garbage collection proposal.
This, the limitations of minimally viable product capability of WebAssembly prior to the realization of proposals, is a frequent complaint. It’s understandable that a language-agnostic compilation target requires additional features to support a wide range of programming languages with different compilers, interfaces, syntax, and more. There’s a reason why the garbage collection proposal was introduced early on in WebAssembly’s development. Despite this early introduction, it’s 2024, and after years the proposal has reached the final stage of proposals for WebAssembly. This proposal is critical for many languages, including Python, to compile to WebAssembly.
This is not an isolated occurrence. WebAssembly is single-threaded, and while there is a proposal for multi-threading support in phase 4, many tools and projects in the past either needed to find workarounds, accept limitations, or discard WebAssembly as a solution.
Even WebAssembly’s core functionality affected the technology’s adoption. Due to WebAssembly’s lack of access to host resources, given its sandboxed isolation (using an isolated virtual machine to mitigate vulnerabilities), WebAssembly components were limited in functionality. This made it challenging to leverage WebAssembly in use cases requiring access to system resources.
The community also grew frustrated with the lack of debugging support, especially for a technology designed for a web development use case, as front-end developers aren’t particularly known for their disassembled binary analysis skills.
Ecosystem Fragmentation
WebAssembly’s debugging leads us to the next challenge: ecosystem fragmentation.
Chrome DevTools and the Firefox browser support binary disassembly of WebAssembly. Wasmtime has source maps. However, many debugging features are not consistently implemented across the WebAssembly ecosystem, and the level of support for features varies.
As another example, tools, such as WasmEdge and wasmCloud, serve similar use cases and lack differentiation. Both are modular WebAssembly runtimes with lightweight execution designed for distributed applications and support Kubernetes. While WasmEdge focuses on an edge computing use case, wasmCloud has also been used in production to facilitate this use case. There’s at least enough overlap to cause more confusion than necessary when contemplating which to use for a project.
As the WebAssembly ecosystem grows, there is an increasing lack of standardized, consistent implementation of tooling and features. This fragmentation divides the community’s efforts and shows a need for a more standardized approach across the ecosystem. Thankfully, some developers in the ecosystem realized this dividing issue and are taking steps to mitigate it. For example, many language-to-WebAssembly documentation pages purposefully take inspiration from wasm-pack’s documentation to build more consistent instructions and development processes.
While not every critique falls into these categories, key complaints primarily involve WebAssembly’s feature implementation or lack thereof and the ecosystem’s lack of standardization, with a sprinkling of misconceptions about the technology (potentially interpreted as a lack of awareness). To reiterate, skeptics are tentatively optimistic, but highlight such concerns that WebAssembly development needs to solve before WebAssembly can “have its moment”.
Whether Fast Or Slow, It’s a Solution
It’s only been within the last year or so that WebAssembly finally realized, or at least glimpsed, the hopes the community carries for the technology. The WebAssembly ecosystem experienced several shifts in 2024, fueling it’s ambitious future as a critical player on the web, cloud, and beyond.
The Component Model is the key to unlocking many of the features designed to address the limitations that skeptics often highlight.
At its core, the Component Model is a framework for language- and host-agnostic interoperability and interactivity with WebAssembly modules (or components). The Component Model:
- Defines how different components (small, self-contained WebAssembly modules), can communicate and coordinate together.
- Allows WebAssembly applications to reuse components, no matter their language of origin, before WebAssembly compilation.
- Outlines access to host resources but maintains limitations and security through the existing sandboxed environment.
Let’s just take a moment to wrap our heads around that idea, because it’s a pretty powerful one. The Component Model allows WebAssembly to be interoperable and interactive with itself and hosts (in the browser and beyond), without compromising WebAssembly’s existing features, but instead opening the door for novel ones. Additionally, the model’s modular approach makes it easier to reuse code, reducing duplication and improving productivity. When you start to consider the use cases this model facilitates, it’s easy to imagine why this idea kindled optimism in skeptics and supporters alike. In 2024, the Component Model entered the first phase of the WebAssembly proposal stage.
How do WebAssembly components implement the Component Model framework?
WASI 0.2 and WIT are critical standards supporting the Component Model framework, especially the framework’s objective to standardize and improve component communication and integration.
WASI 0.2 provides WebAssembly applications access to system resources with structured permissions. It serves as a way to access resources like filesystems, network sockets, and environment variables. WASI 0.2 resolves barriers to host access. Sandboxed security isolates WebAssembly code from the host system, limiting the component’s ability to access the system’s resources. WASI’s system APIs allow WebAssembly applications to access system resources with structured permissions and flexible interfaces, thereby maintaining security.
WIT, the WebAssembly Interface Type, defines a communication layer between WebAssembly components written in different languages. It simplifies cross-language interoperability so that components interact smoothly regardless of programming language. WIT ensures components can send and receive data without compatibility issues, opening the doors for complex, modular WebAssembly applications.
Imagine a deployed cloud service containing multiple components, with one component written in Rust and another component written in Python. Through WIT, these components can communicate with each other. By leveraging WASI 0.2 system APIs, the components can access system resources, but only resources that were explicitly defined. This cloud service’s components are also modular and can be reused in another service to facilitate the same process.
These standards and tools build the ecosystem-wide standardization and consistency that WebAssembly needs to reinforce the technology’s core functionality for the many diverse use cases of WebAssembly. As for the misconceptions mentioned earlier and community fragmentation, these challenges will be mitigated as the technology gains consistent standardization that increases adoption, documentation, and community awareness of WebAssembly’s use cases and capabilities.
The Component Model, WASI 0.2, WIT, and the tools implementing this framework will address the challenges that impact WebAssembly’s usability and adoptability. It already is, with several WebAssembly projects this year implementing The Component Model despite its early proposal phase.
WebAssembly’s Ambitious Future
Imagine a fintech company that leverages WebAssembly to process financial transactions. While the primary logic may be written in Rust for speed and security, the integrated machine learning model is written in Python, and the application frontend in JavaScript. The components function efficiently within a single WebAssembly application.
This year, credited mainly to the Component Model, this scenario sounds more like a possibility than ever.
While the Component Model is only a phase 1 proposal in 2024, it offers the capability that the community wants and the solutions to issues critics highlight. By enabling modularity, easing access to system resources with WASI 0.2, and improving cross-language communication through WIT, the Component Model addresses the limitations that hold WebAssembly back from greater utility.
About the Author
Aleks Jones is a technical trainer and course author at The Linux Foundation, focusing on emerging technologies like WebAssembly and Cybersecurity. As an editor for the Evil Tux blog, she evaluates technical articles sharing insight on Artificial Intelligence and Cybersecurity. In her leisure, she participates in capture the flag competitions.