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.
What’s WASI?
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.
“That’s really what WASI is — a set of APIs, a common set of APIs and if you target that common set of APIs, you’re now able to run really well outside of a browser or really outside of any JavaScript runtime,” Hayes said.
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 way the world works today, because you exist in the JavaScript ecosystem and I exist in the Rust ecosystem, we can’t intersect, and that means that entire swaths of developers, your frontend people and your backend people treat each other almost adversarially,” Hayes said. “That’s part of what the component model is meant to enable, is that I can seamlessly work across language boundaries in a portable way.”
With the component model, developers could build a library in C++, a library in Rust, and a library in Python — or any other language, including JavaScript — and be able to build them together like Lego bricks, to make a complete application, she explained. And since security is the first concern for WebAssembly, they’d be able to do it in a secure way.
“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,
Currently, the focus is on Rust, JavaScript, C++, but some people are also working in Ruby, Python and Go. But it’s not limited to those languages, Hayes stressed.
“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.”
Take, for instance, JavaScript, where the ecosystem typically involves npm — the node package manager.
“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.”
The Emscripten toolchain is a good place to start, she added. It’s helpful for people who know JavaScript and want to learn a little C++, for example, or who know C++ and want to learn how to do just a little bit in JavaScript to make their app work in the web. Rust is another good starting point.
“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…
|
1 |
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.
