WASI Preview 2: What WebAssembly Can and Can’t Do Yet
WebAssembly’s WASI Preview 2 may not be considered a groundbreaking development, but it holds promise for the future.
The new WebAssembly System Interface (WASI) standard is a step in the right direction, potentially paving the way for WebAssembly to fulfill its hype and promise. Paradoxically, its current state is not necessarily timely. Arguably, it arrives late, albeit not due to any fault of the vibrant and active community developing WebAssembly and, in this case, the component model.
The release thus does not portend a new age for WebAssembly, making it more of a delayed milestone than a new beginning. Indeed, the WASI standardization work has been in progress for a long time, predating much of the widespread use of WebAssembly in applications and it’s still not completely ready.
In this context, Wasm’s evolution has led to the need for a component model and especially its relationship to WASI, which is the standard Interface or API linking the web assembly modules to the components. A WebAssembly component plays a critical role in how runtimes that run inside WebAssembly modules are deployed.
Once finalized, a component model that will enable WebAssembly to not just see its expanding use beyond web browsers and servers — but will be able to allow users to deploy different applications running inside numerous lightweight modules at very high speeds across thousands of endpoints simultaneously through a component interface called the without changing one iota of code.
“While WASI Preview 2 is an important ‘stake in the ground’ and shows the great vision of what WebAssembly apps could eventually become, we also need to be clear on the fact that there is still much work to do and it will have to be done quickly before the enthusiasm dies down,” Torsten Volk, an analyst at Enterprise Management Associates (EMA), told The New Stack.
While a small step, WASI Preview 2 “is needed now,” Daniel Lopez Ridruejo, founder and former CEO of Bitnami (now part of VMware), told The New Stack. “WASI Preview 2 means Wasm, and WASI in particular, are going in the right direction and hopefully this will accelerate things,” as a component API will hopefully catch on and eventually become generally available, he said.
The World
WASI Preview is noteworthy because it brings Wasm closer to the a finalized component model, contingent on “worlds.”
Dan Gohman, one of Wasm’s main contributors and creators, in a recent blog post notes how the WASI Subgroup officially says that the Preview 2 APIs are stable and that Preview 2 includes two “worlds”:
- wasi-cli, the “command-line interface” world, which roughly corresponds to POSIX. Files, sockets, clocks, random numbers, etc.
- wasi-http, an HTTP proxy world, organized around requests and responses.
“One good thing about the WASI Preview 2 delay is that now WASI has fully embraced the component approach — a piece of the Wasm ecosystem that didn’t stabilize until late 2023. Even as the standards move forward, it is now possible to use worlds to declare dependencies at a programmatic level,” Matt Butcher, Fermyon co-founder and CEO, told The New Stack. “This is a huge boon for compatibility and interoperability (and helps prevent noxious fragmentation of the Wasm ecosystem). I have been impatient about WASI Preview 2, but in hindsight, I have to say that rebasing WASI on top of the component model was the right call to make.”
The Dream Continues
The hype surrounding WebAssembly is attributed to its potential to offer an API, connecting languages from one endpoint to another or distributing from one endpoint to multiple endpoints through concise lines of code in a single module. The WASI standard plays a crucial role in enabling this eventual capability.
As Gohman, in a post announcing the preview writes: “Work towards Preview 3 will be getting underway. The major banner of Preview 3 is async, and adding the future and stream types to Wit. And here again, the theme is composability. It’s one thing to do async, it’s another to do composable async, where two components that are async can be composed together without either event loop having to be nested inside the other. Designing an async system flexible enough for Rust, C#, JavaScript, Go, and many others, which all have their own perspectives on async, will take some time, so while the design work is starting now, Preview 3 is expected to be at least a year away.”
However, the current state of WASI does not indicate WebAssembly’s overall shortfall. Paradoxically, WebAssembly has achieved significant adoption for web browsers and servers, thanks to its large and growing open source community continually enhancing this aspect.
Although less advertised, WebAssembly has been in practical use for a couple of years in this manner. Moving on to the breakthrough at hand — the alleged development of WASI, as eloquently outlined by Gohman — it offers promise.
Gohman also writes: “There is still a lot more to do, in writing more documentation, more tests, more toolchains, more implementations, and there are a lot more features that we all want to add. This vote today is a milestone along the way, rather than a destination in itself. “
WASI Preview 2 is not exactly a groundbreaking development, but it does provide insight into what WebAssembly can and should be. Most developers aren’t concerned with the intricacies of WebAssembly, although some, driven by intellectual curiosity and a passion for computing, find it fascinating.
In terms of practical application, many developers simply want to seamlessly integrate an application written in their preferred language. This desire extends beyond challenging-to-learn languages like Rust and Python, or Go, and includes the incorporation of JavaScript. The process involves writing the application, adding it to the WebAssembly module, and subsequently distributing it to potentially thousands of endpoints through a single module. This distribution can occur on AI devices embedded in various devices, servers or any location with a CPU running an instruction set.
More Work
What WASI Preview 2 does now is to provide a “glimpse into an exciting new world of completely modular apps where each module can be written in a different language, yet all modules can communicate between one another and with the outside world via the component model,” Volk said. “Ultimately, this could enable us to add on or eliminate new app capabilities at runtime.”
However, two main questions arise, Volk noted: what can we do with wasi-cli and wasi-http right now and when will the rest of the component model be defined? The response is that wasi-http lets us send and receive data via HTTP responses and wasi-cli provides us with the ability to interact with the operating system via the command line, Volk said. This should allow for the creation of microservices and web servers that can communicate via HTTP calls and execute basic computation tasks. “However, as WASI 0.2 does not provide access to databases, file systems, messaging, GPUs, file systems or the physical network and as the standard UI libraries and multithreading all are not available, our microservices and web servers are limited in what they can do,” Volk said. “While there are workarounds, like for example interacting with databases via HTTP, WASI 0.2 does not yet offer a turnkey developer experience.”
Meanwhile, WASI Preview 2 represents a step in the right direction, marking a significant milestone. It contributes to the overarching goal of enabling the distribution of applications, ushering in the potential for this on various computing platforms. While this is a milestone, significant development is still required to establish it as a common standard as described above. “Components and WASI Preview 2 both foist considerable work on WebAssembly runtime developers and compiler engineers. But this is work with obvious benefits. Wasmtime, Rust, Kotlin, Python, JavaScript, and other runtimes and languages are already moving ahead quickly,” Butcher said. “I will be surprised if we do not see widespread adoption of WASI Preview 2 and components by mid-2024. Yes, I genuinely think it will happen that fast.”
Each WASI release also opens new possibilities for employing Wasm, Butcher said. “That is a double-edged sword. Yes, it is great to see progress, But if we can’t collectively get things done in a more timely manner, we’re at risk of impatience driving implementers away,” Butcher said. “Unlocking one new feature set increases the pressure to unlock the next one sooner.”
