Four upcoming features promise to expand WebAssembly’s power and scope, but developers and language designers will have to do their part.
WebAssembly gives developers a whole new way to deliver applications to the web and beyond. Instead of writing solely in JavaScript, developers can write in various other languages, compile that to WebAssembly’s bytecode format, and run it in a sandboxed environment at near-machine speeds.
But Wasm (the popular abbreviation for WebAssembly) is also relatively new, and it’s still evolving in fits and starts. Key features that would massively expand Wasm’s power and usefulness aren’t there yet or must overcome major obstacles before they can be rolled out.
Here’s a rundown of the most anticipated features on the horizon for Wasm. I’ll explain what they do, why they matter, and what it’ll take to implement them. Some are still a ways off, while others are already available in provisional form.
Async
JavaScript, and web apps generally, rely heavily on asynchronous operations. Wasm’s specification, WASI, doesn’t yet natively support async I/O, but one of the key features promised for WASI 0.3 (originally planned for March 2025) is native support for async. With this addition, it will be possible to implement or call functions asynchronously.
Right now, any Wasm code that wants to use async behaviors must resort to a variety of awkward workarounds. Options include launching multiple Wasm instances or nonstandard approaches to allowing callbacks from a host that is dependent on a particular runtime’s way of doing things. The WASI 0.3 async plan lays out an official, blessed way to do async in the runtime and in WebAssembly itself. It also includes plans for the existing WASI 0.2 spec to have async support polyfilled or virtualized.
Not everything that async needs will be supported out of the gate. For instance, 0.3 won’t roll out a cancellation protocol for async tasks; that’s slated to be added in a later 0.3.x release.
Multi-threaded execution
Another major missing feature in Wasm and the WASI spec is support for threading. Wasm runtimes run single-threaded, which severely hobbles workloads that otherwise benefit from threading. Some existing workarounds are similar to how developers cope with the lack of async—for example, by spinning up multiple instances of the runtime and splitting workloads between them. But those solutions are bulky and inelegant.
Adding multithreaded execution to WebAssembly isn’t on the 0.3 roadmap, but there is an extant, approved proposal for doing it. Threads, called agents in the proposal, provide for shared memory between agents and atomic operations for memory access. Another proposal, shared-everything-threads, goes further with more advanced, forward-looking features, including compatibility with the proposed garbage collection mechanisms for Wasm.
Shared memory
Shared memory goes hand in hand with threading. The existing threading proposal brings with it a basic plan for how to share memory between components, but it’s mostly a way to share raw regions of linear memory. It’s not intended for sharing complex data objects.
A recent standard addition called multiple memories offers a more robust option. Memory segments can be defined in an application and isolated from each other, only sharing what needs to be shared. The next step is to allow better support for this feature in languages that compile to Wasm. Rust, for example, has explicit support for multiple memories. (One of the valid arguments for Rust being an excellent first choice for compiling to Wasm is how quickly and effectively it implements evolutionary changes to the Wasm runtime.)
Garbage collection
Many higher-level languages use automatic memory management, including JavaScript, C#, Java, Python, and Swift. Memory-handling details, like allocating memory and releasing it when it’s no longer needed, are left to the runtime.
Originally, the WASI spec and Wasm runtimes did not have native support for garbage collection or garbage-collected structures. Any language compiling to Wasm that wanted to support those features had to roll its own garbage collection. For instance, the Go and Python languages each include their own garbage-collected runtimes. The downside is the entire runtime must be included with every Wasm program. Adding native garbage collection to Wasm would allow ports of those language runtimes to use WASM’s own garbage collection mechanisms wherever possible.
The first iteration of garbage collection is now available in Wasm, but like the other proposals I’ve mentioned, it’s only enough to get things started. One important point for even this early iteration of Wasm GC is that you don’t pay for it if you don’t use it. Wasm programs that never use garbage collection will see no changes to their code.
Two things are coming next. The first is more robust features for Wasm GC, such as safe interaction with threads. Another is to have compilers that target Wasm and Wasm-ported runtimes utilize Wasm GC. For this to work, the compilers and runtimes in question will need to be modified. The Kotlin language, for instance, has introduced a Wasm implementation that uses Wasm GC, although it’s still considered an alpha-quality project.
The path to garbage collection reveals a pattern for other major Wasm features to come. Just having a feature defined formally in a spec or added to the available runtimes isn’t enough. All the languages that compile to Wasm must support the feature directly to make the most of it, and the timeline for that will vary with every language. That said, languages that can compile directly to Wasm (like Rust) will likely be quicker to add support, while those with a ported runtime (like Python or Go) will lag. Implementing support for new features is more straightforward for languages that compile directly to Wasm than for those that don’t.
