WasmCon 2023: The Rise and Realization of the WebAssembly Component Model
Ivan Towlson
wasmcon
component model
conference
roundup
In retrospect, the defining image of WasmCon 2023 was one that I didn’t even think to take a picture of at the time. In the style of a metro map, Bailey Hayes’ keynote laid out a set of work streams, all converging on a central point: the delivery of the first stable version of the WebAssembly (Wasm) Component Model. It asked: are we there yet? And the answer was: actually, pretty much, yes.
The component model wasn’t the only story of WasmCon, of course. The “better together” theme reflected not only how projects within the Wasm community benefit each other, but also Wasm’s growing role in the broader cloud ecosystem. But if there was one major thread across the two days, this was it: the realization of the Wasm component model vision.
If you’re interested in non-component highlights, my personal ones were Ralph Squillace, daring to “build a Linux just for Wasm” live on stage; Dirk Bäumer, making Visual Studio Code language servers work on the Web by the magic of WASI virtualization; and Dan Chiarlone, beefing up the Wasm sandbox with a super speedy hypervisor. You can find all the talks on the Linux Foundation YouTube.
Three of the keynotes focused on the Wasm component model, but in contrasting ways. Luke Wagner’s “What is a Component (and Why)? set out the motivation, principles, and vision, as well as drilling in on some technical scenarios the component model is uniquely placed to enable. Liam Randall’s “WASI Standards and the Component Model” looked forward to Wasm’s “Docker moment” - a technical alignment that enables developers to build tools on a shared common basis. And Bailey Hayes’ “Are We Componentized Yet?” provided a “state of the programme” survey of what it was going to take to deliver a stable, working, and usable first version of the Wasm component model. It was great to have these two perspectives, the visionary and the practical, side by side.
Fermyon had a keynote too - introducing a new set of Serverless AI features, now in private beta. We also welcomed attendees to a “cocktAIl affAIr” to chat about AI, the Wasm Component Model, and all things Wasm!
The component model breakout sessions, by and large, focused on those practical matters. Here’s the metro map from Bailey’s keynote that I mentioned earlier:
Let’s take a look at some of the “lines” of the metro.
Languages, Bindings and Registry
Kyle Brown heads up the Guest Languages Special Interest Group of the Bytecode Alliance. His talk “Components for Every Language” not only showed Wasm components built using JavaScript, Python, C, and Rust all working together seamlessly, but also revealed a little bit of the plumbing that made it all work.
Fermyon boffin Joel Dice went into deeper detail on one language, introducing the componentize-py tool for packaging Python applications as Wasm components. If you’ve used the Spin Python SDK then you’ll know Joel has form in this area. But componentize-py goes way beyond spin py2wasm, providing for the full generality of the Wasm component model, and delivering the native extensions that many Python applications depend on. Native extensions, in particular, open up the Python scientific computing stack, and the de facto standard toolchains for machine learning and language inferencing - the sort of things that feeds into Fermyon’s Serverless AI. If you’d like to learn more about componentize-py, check out Joel’s recent blog article.
Other talks I didn’t get to included Daniel Macovei on the WebAssembly Registry project and Zalim Bashorov on Kotlin.
Compilation, Linking and Runtimes
Guy Bedford talked about the jco JavaScript toolset, which allows you to build Wasm components from JavaScript, convert components to JavaScript, and run components either at the command line or in the browser. As well as its importance bridging the component and JavaScript ecosystems, jco provides an independent implementation of the Wasm component model, a crucial step in validating the specification and testing portability.
We also got an update on Wasm GC (Garbage Collection) from Ivan Mikushin, an crucial runtime feature for languages such as Kotlin.
Documentation
Although WasmCon itself didn’t have any sessions about documentation, it was a topic at the Bytecode Alliance’s “Componentize the World” event the day after, with volunteers from around the ecosystem hammering away on user-facing documentation for the imminent preview release, and a proposal for a group to support and champion documentation in future.
Worlds and Interfaces
Joel teamed up with Jiaxiao Zhou to take WASI-Cloud-Core for a spin. One of the most potent architectural decisions of the Wasm component model is to break with the traditional idea of a single low-level POSIX-a-like API in favour of multiple “worlds” whose APIs can be as low- or high-level as is useful for their purpose. Brendan Burns’ keynote described how cloud native applications employ primitives like “key-value store” and “event stream” rather than “file” or “socket”; Joel and Jiaxiao made that concrete, presenting a world with an API built for the cloud. This API abstracts common concerns away from application code, meaning there’s no risk of business logic taking a dependency on, say, a particular queue implementation. And there’s now a Spin fork that implements this world! No standard existed when we started the Spin project, so the released world is ad hoc, but it was exciting to see the world Spin is going to inhabit, and to see “worlds as environments” being made real!
Componentize the World
The Bytecode Alliance held a “Componentize the World” hackathon the day after WasmCon. This was a great opportunity to get hands on with the Wasm component model, shake out a few bugs and pain points, and fill in some of the remaining work.
The Wasm Component Model: Ready, Set, Build!
Even its staunchest fans admit that the Wasm component model has been a long time coming. The message from WasmCon and “Componentize the World” is that, apart from a few final details, it’s here. The tools work; there’s documentation on how they work; and they work together. Let’s get building!