WebAssembly to Let Developers Combine Languages
What if there was a way to use libraries from whichever programming language you wanted and compile them together? And what if developers could do that not in the distant future, but by year end?
That’s exactly the problem the Bytecode Alliance plans to solve this year, according to the newly-appointed director of the Bytecode Alliance Technical Steering Committee, Bailey Hayes.
“We’re working on the roadmap,” said Hayes, who is also a director at the Wasm cloud company Cosmonic. “We have demos of this working — bubble gum, some wire, it works. But I expect us to have more real demos, probably by the end of the year. We’re talking a matter of months, not years.”
The Bytecode Alliance Foundation is a nonprofit organization that works on implementing a software foundation based on the W3C standards, including WebAssembly (aka, Wasm) and WebAssembly System Interface (WASI). Originally founded by Mozilla, Fastly, Intel and Red Hat in 2019, the Alliance’s first goal for the Wasm ecosystem is to ensure it remains secure and deny-by-default, Hayes said.
Originally, WASI was called “POSIX-like,” referring to “Portable Operating System Interface” — which is defined in Wikipedia as “a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems.” That analogy proved confusing, however.
“It’s not meant to be POSIX — that’s a common misconception,“ Hayes told The New Stack. “What we really meant was, there’s a common set of APIs that you expect, they [developers] can almost treat like this runtime that you’re targeting, and that lets you run really well outside of the browser. There’s certain things that just about every application depends on or expects. If you don’t have that, then you’re very restricted to what the WebAssembly module is allowed to do.”
WASI gives developers the capabilities such as accessing a file system, doing standard I/O, and other capabilities that developers get out of libc, which stands for the standard C library. Developers will call them standard foreign function interface (FFI) bindings, Hayes said, but really they are handles that the host runtime gives the WebAssembly module in a capability-driven way.
A Preview of WASI Preview 2: The Component Model
That was the work of WASI Preview 1, which is stable. The ByteCode Alliance is now working on WASI Preview 2, which is expected to launch sometime this year.
“I think it’s going to be a big deal,” Hayes said. “It moves us to this new proposal that we’ve also been working on, another standard. It started off being called the interface-types proposal, but that has now folded into what we call the component model.”
The component model is basically a new operating model — a new way for people to build WebAssembly applications. This will allow developers to break down language silos and combine libraries from other languages, using Wasm as a language “one ring” to bind them.
“The easiest analogy that people will understand is that it’s like going from a static library, static executable, to being able to work with dynamic libraries — but in terms of WebAssembly modules and with strict types and being able to expose those types to other WebAssembly modules that are components,” Hayes said. “It means that we completely change the way that we write software today. It means all of these silos that have existed for 20 years are gone.”
It’s not hard to see how revolutionary that could be for software development,
“It’ll start small and I think it’ll grow exponentially,” she said.
Building a Component Registry
The Bytecode Alliance also has a special interest group working on building a component registry, although Hayes said that is still “very early days.” Its goal is to design a protocol so that other registries can speak the language of components, such as knowing what the component types are.
“Again, we have to circle back to the reason why we’re designing our own registry and our own protocol is so that we’re pulling in the latest advancements in security as far as content hashing, making sure everything’s signed the right way, and having an immutable log.”
“In that registry, if you said npm install, maybe there’s some new flag that we invent, but some new flag that says I’m dealing with a component, and it pulls in a component that’s using what we call the WARG protocol — the WebAssembly registry protocol,” she said. “That would make it so that you would be able to install components that were in theory written in any language, so you don’t have to learn that other language.”
Then developers only need to know things like which pieces from the library are needed and what functions to call. Last week at Cloud Native Security Con, Kyle Brown provided an overview of a new protocol called Warg (WebAssembly ReGistry) and isssued a call for security researchers to help with the registry.
“We don’t want to make the same mistake as basically every registry before us has in the past,” Hayes said.
Where Developers Can Start with WebAssembly
While the details of WASI Preview 2 are still being ironed out, there’s a lot that has been standardized with WebAssembly that developers can experiment with, Hayes said.
“WASI Preview 1 and also just the WebAssembly specifications 1.0 and 2.0 [are] super well supported everywhere,” she said. “Say you want to take languages that aren’t currently supported in the web, and run them on the frontend, that’s a great use case that is solid.”
“Once WebAssembly work became underway, then it felt like Rust just exploded on the scene,” Hayes said. “So the two technologies have really co-evolved over time and what that means for somebody getting started working with Rust and WebAssembly is very seamless. It’s a solid developer experience.”
For example, using…
cargo build --
…to target a wasm32 binary. That can then be run with a Wasm runtime such as Wasmtime. Wasmtime makes it possible to have Wasm modules in many different places, like on the desktop, at the edge, as a serverless function, etc., Hayes explained.
She concluded that the work being done within the Bytecode Alliance is about building a software foundation for Wasm that’s secure-by-default, capability-driven, and portable. They want the ecosystem to extend to many different environments, from the web to the edge. She encouraged anyone who is interested in contributing to any of their projects within the alliance to watch the monthly community stream for an overview and to join Zulip to chat about the development of Bytecode Alliance projects.