WASI 0.2: Unlocking WebAssembly’s Promise Outside the Browser

Key Takeaways:

The launch of WASI 0.2, also known as WASI Preview 2, is being celebrated by the developer community as it represents an official stabilization point for both the Component Model and a collection of WASI APIs.
This establishes a robust and versatile foundation for WebAssembly outside the browser, allowing it to be used in a wider range of applications.
This advancement allows developers to build software like LEGO bricks, where different components can easily be connected to create more complex apps.

The WebAssembly System Interface (WASI) Subgroup recently reached a significant milestone by voting to launch WASI 0.2, also known as WASI Preview 2. This exciting new WASI standard is based on the Wasm component model, allowing application developers to build software like LEGO bricks, where different components can be easily connected to create larger and more complex applications. This approach makes it simpler to write, reuse, and maintain code while ensuring that the final product is secure, fast, and compatible across different devices and systems.

Looking Back: The Evolution of WebAssembly and WASI

WebAssembly was originally developed with the browser in mind so people could run performance-critical code or heavy workloads like image-editing programs and video games in the browser. Concurrently, there was considerable discussion about its potential outside of browsers. Node.js was successful in doing this with JavaScript, and the developer community had similar aspirations for WebAssembly.

But this desire was fraught with complexity. WebAssembly depended heavily on running in web browsers and lacked direct access to system resources and APIs outside of the browser environment. There were also concerns around sandboxing and security, which were crucial considerations in the context of browser execution, with sandboxing ensuring that code executed within the browser couldn’t access sensitive system resources or interfere with other browser processes.

However, despite these initial limitations, the vision to extend WebAssembly beyond the browser environment prevailed. As developers and stakeholders began to recognize its potential for secure, cross-platform application development, they worked to broaden its scope. This led to the development of WASI, which aimed to provide a standardized interface for executing WebAssembly code in non-browser environments such as servers, command-line tools and embedded systems.

The introduction of WASI Preview 1 in 2019 included features aimed at helping WebAssembly interact with the outside world such as the filesystem and the command-line interface. WASI Preview 1 resembles a super-portable subset of POSIX, the Portable Operating System Interface, which left open the question of whether to go the rest of the way toward POSIX, following a well-trodden path that we knew would lead to containers, or whether WASI should forge a new trail toward something that could be fundamentally lighter weight, faster to start, more secure and more resistant to supply chain attacks.

After spending some time working in the POSIX direction with Preview 1 and developing a shared vision of the future, we decided to embark on the second path, forging a new trail but also creating a bunch of new questions.

The Component Model Enters the Story

Once we decided to venture off the well-trodden POSIX path, we needed to find something new to take the place of POSIX-style executables and shared objects, which are the primary units of code in a traditional POSIX system upon which applications are built. After distilling a motivating set of goals and use cases, we decided on a high-level design for a new unit of code called a “component” that would be built on top of and contain WebAssembly modules.

So what is the difference between a module and a component? Modules, which are already fully standardized and supported in browsers, contain very low-level code that tries to be as close to the CPU as possible (while ensuring safety and portability).

Components bring the magic by acting as a wrapper around the module and knowing how to interact with other components no matter which language they are written in. Components also help resolve a number of security issues by providing a structured way for modules to communicate and interact with each other without sharing low-level memory, kind of like traditional POSIX processes. This helps reduce the risk of unauthorized access or malicious behavior, as well as helps to mitigate the risk of vulnerabilities spreading across the system.

WASI 0.2: A Significant Step in the Right Direction

The developer community is celebrating the launch of WASI 0.2 as it marks an official stabilization point for both the Component Model and a collection of WASI APIs, and establishes a robust and versatile foundation for WebAssembly outside the browser. The launch is just the beginning and there is still a lot of work ahead, but it provides a line of sight toward completely modular apps and new possibilities for composability and compatibility.

WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal.

The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.

Looking Ahead: The Future of WASI

As WASI continues to evolve, there are exciting prospects on the horizon. The roadmap for future releases includes plans for incremental updates, feature enhancements and support for composable concurrency. The goal is to create a robust ecosystem that can accommodate diverse use cases and programming languages, including Rust, C#, JavaScript, Python, C++, Kotlin and Go.

The principles of composability and compatibility will guide the transition from WASI 0.2 to future versions. With the flexibility of the component model, WASI aims to facilitate seamless upgrades and interoperability between different versions. This iterative approach ensures that WASI remains adaptable to emerging technologies and evolving developer needs.

Celebrating a Milestone in WebAssembly’s Journey

WASI 0.2 symbolizes the culmination of years of collaborative effort and innovation, paving the way for a new era of cross-platform development and deployment.

As we look to the future, the journey of WASI continues, driven by the collective vision of a vibrant and diverse developer community. With each release, WASI brings us closer to a world where code portability, security and interoperability are not just ideals but fundamental principles of software development.