Can WebAssembly Get Its Act Together for a Component Model?
The final mile for WebAssembly remains a work in progress as the Wasm community races to finalize a common standard. Among other things, it is in the wait of the standardization of component interface Wasi, the layer required to ensure endpoint compatibility among the different devices and servers on which Wasm applications are deployed. As progress has been made so apps written in different languages can be deployed with no configuration among numerous and varied endpoints, the survival of WebAssembly as a widely adopted tool remains at stake until such a standard is completed. However, the community is aggressively seeking to finalize the component module, which became apparent during the many talks given at the first Linux Foundation-sponsored WasmCon 2023 last week.
“WebAssembly has boasted a handful of small advantages over other runtime technologies,” Matt Butcher, co-founder and CEO of Fermyon Technologies, told The New Stack. “The component model is the big differentiator. It is the thing that opens up avenues for development that have simply never existed before. It’s fair to call this an existentially important moment for WebAssembly.”
Implementations for WASI-Preview 2
This roadmap released in July reflects changes occurring in standards within the WebAssembly CommunityGroup (CG) and the WASI Subgroup within the W3C. This includes the WebAssembly Core WebAssembly Component Model, WASI (WebAssembly System Interface) and a number of WASI-based interfaces.
The Component Model proposal, developed on top of the core specification, includes the WebAssembly Interface Types (WIT) IDL, while WIT is the language of high-level types that are used to describe the interfaces of a component, as Bailey Hayes, director of the Bytecode Alliance Technical Standards Committee and CTO at Cosmonic, explained in a blog post.
The Component Model adds high-level types with imported and exported interfaces, making components composable and virtualizable, Hayes said. This is important for allowing different programming languages to function in the same module because it allows for the creation of and combining components that were originally written in different programming languages, Hayes said.
The latest standards for WebAssembly (Wasm) are of significant importance as they focus the efforts of developers, community members, and adopters on tooling that supports a portable ecosystem, Liam Randall, CEO and co-founder of Cosmonic, told The New Stack. “With a focus on WebAssembly Components, they enable Components to act as the new containers, ensuring portability across various companies developing across the landscape,” Randall said. “This standardization also fosters better collaboration between language tooling that creates components from various languages and hot-swappable modules defined by WASI. What this means to developers is that we can now use code from across our language silos, creating a powerful ‘better together’ story for the WebAssembly ecosystem.”
In other words, WASI-Preview 2 is an exciting step as it addresses critical areas such as performance, security and JavaScript interactions — and one more step on the journey toward interoperability, Torsten Volk, an analyst for Enterprise Management Associates (EMA), told The New Stack. “The common component model is absolute key for accelerating the adoption of WebAssembly, as it is the precondition for users to just run any of their applications on any cloud, data center or edge location without having to change app code or configuration,” Volk said.
An API call requesting access to a GPU, a database or a machine learning model would then work independently of the specific type of the requested component, Volk said. “This means I could define how a datastream should be written to a NoSQL database and the same code function would work with MongoDB, Cassandra or Amazon DynamoDB,” Volk said.
WASI began as a POSIX-style library for WebAssembly. However, it has outgrown those roots, becoming something more akin to JavaScript’s WinterCG: a core set of interfaces to commonly used features like files, sockets, and environments, Butcher said. “WASI Preview 2 exemplifies this movement away from POSIX and toward a truly modern set of core features. Instead of re-implementing a 1970s vision of network computing, WASI is moving to a contemporary view of distributed applications.”
Check out @Dicejw's post on the @fermyontech blog: Introducing Componentize-Py.
My favorite feature: you can build #WebAssembly components written in #Python with dependencies that use native extensions.
I can use NumPy in my @spinframework apps!https://t.co/6JoWjsVkN7 pic.twitter.com/0i0fOSdu0a
— Radu Matei (@matei_radu) August 29, 2023
The component aspect plays a key role in the release of new features for Fermyon’s experimental SDK for developing Spin apps using the Python programming language.
Relating to components, Fermyon’s new componentize-py can be used to build a simple component using a mix of Python and native code, type-check it using MyPy, and run it using Spin. The user can then update the app to use the wasi-http proposal, a vendor-agnostic API for sending and receiving HTTP requests.
“Providing developers with the ability to integrate with runtime elements that are not yet completely defined by a CCM makes it less likely for them to hit a wall in their development process, and should therefore be welcomed,” Volk said.
Regarding Python, it is a “top language choice, and is vitally important for AI,” Butcher said. “Yet, to this point some of the most powerful Python libraries like NumPy have been unavailable. The reason was that these core libraries were written in C and dynamically loaded into Python,” Butcher said. “Who would have thought that the solution to this conundrum was the Component Model?”
With the new componentize-py project, Python can take its place as a top-tier WebAssembly language, Butcher noted. “Most excitingly, we are so close to being able to link across language boundaries, where Rust libraries can be used from Python or Go libraries can be used from JavaScript,” Butcher said. “Thanks to the Component Model, we’re on the cusp of true polyglot programming.”
Future Work
A very good definition of a #WebAssembly component, @fastly's @luke_wagner communicated during his #WasmCon 2023 keynote "What is a Component (and Why)?": A standard portable lightweight finely sandboxed cross-language compositional module. https://t.co/JSkkCDCFKO #WasmCon pic.twitter.com/P7rVtGUwoO
— BC Gain (@bcamerongain) September 7, 2023
The work to finalize a component model that is necessary for Wasm to see wide-scale adoption remains ongoing, as an extension of the incremental steps described above, Luke Wagner, a distinguished engineer for edge cloud platform provider Fastly, told The New Stack during WasmCon 2023 last week. Wagner defines a component as a “standard portable, lightweight finely-sandbox cross-language compositional module.”
@fastly‘s @luke_wagner described during his #WasmCon 2023 keynote the roadmap for this year and next for #WebAssembly‘s component model. https://t.co/JSkkCDC7Vg pic.twitter.com/SXtjhKvx49
— BC Gain (@bcamerongain) September 13, 2023
During his conference talk, Wagner described the developer preview to be released this year:
- Preview 2: It covers both a component module and a subset of Wasi interfaces.
- The top-line goals are stability and backward compatibility:
“We have an automatic conversion converting Preview 1 core modules to Preview 2 components and then we’re committing to future having a similar tool to convert to Preview 2 components into whatever comes next,” Wagner said during his talk.
Preview 2 features include, Wagner said:
- A first wave of languages that include Rust, JavaScript, Python, Go and C.
- A first wave of Wasi proposals, including filesystems socket, CLI, http and possibly others.
- A browser/node polyfill: jco transpile.
- Preliminary support for Wasi virtualization in the form of wasi-virt.
- Preliminary support for component composition: in the form of Wasm-compose.
- Experimental component registry tooling: in the form of warg.
- “Next year it’s all about improving the concurrency story,” Wagner said. This is because Preview 2 “does the best it can but concurrency remains warty.”
These “wart” aspects Wagner described include:
- Async interfaces, which are going to be too complex for direct use and need manual glue code, while the general goal is to be able to use the automatic bindings directly without manual glue code.
- Streaming performance isn’t as good as it could be.
- Concurrency is not currently composable, which means two components doing concurrent stuff will end up blocking each other in some cases. And if you’ve virtualized one of these async interfaces, it ends up being that you have to virtualize them all.
Preview 3 will be designed to:
- Fix these drawbacks by adding native future and stream types to Wit and components.
- This will pave the way for ergonomic, integrated automatic bindings for many languages.
- Offer an efficient io_uring-friendly ABI.
Composable concurrency: For example, in Preview 2, we need two interfaces for HTTP: one for outgoing requests and one for incoming ones that have different types and different signatures, Wagner said. With Preview 3, the two interfaces will be merged to just have one interface, i.e. with the Wasi handler.
This will allow for a single component that both imports and exports the same interface: It will then be possible to import a handler for outgoing requests and export a handler to receive incoming requests. Because they use the same interface, it will then be possible to take two services to chain together and just link them directly together using component linking and now executing the whole compound request is just an async function call, which can support modularity without a microservices use case.
“Our goal is by the end of this year is to complete Preview 2 milestones, which will lead to a stable, maybe beta release,” Luke Wagner, a distinguished engineer for Fastly, told The New Stack after the WasmCon 2023 last week.
“The idea is, once we hit this, you will continue to be able to produce Preview 2 binaries and run them in Preview 2 engines so stuff stops breaking.”
