Around June of 2024, long after pi day, I decided to check in to see what had changed in the Web Assembly ecosystem. Wow!
Some things were predictable.
- Progress on package repositories - e.g., wasmer.io registry and warg
- ... and composition - e.g., wac and spin from fermyon moves to fully open planning
- etc. - there were several previews we learned about late last year ...
But, then we learned more at WASM I/O 2024:
- WASI 0.2 was announced
- Component Composition using warg was demoed - WHOA!
- Compiling Python to Native Wasm using wasmer.io py2wasm - a little easier to use than pyodide, but still produces large wasm files & requires Python 3.11 (not 3.12+)
- Deconstructing WebAssembly Components demoes the diff between core modules and composable modules with share-nothing vs share-everything architecture via an introduction to Component Model as well as introduction to type lowering and lifting
- extism 1.0 - higher level framework that helps tie all the specs together to improve DX
- Paint by Numbers: High Performance Drawing in Wasm showed some improvements coming to wasi-webgpu
- This blew my mind! WANIX: A WebAssembly Operating and Development Environment that introduced a project that is really stretching the boundaries of what can be done with the component model and WASI
- The Smallest Thing That Could Possibly Work - demoed using wasm to control a DJI drone!
- Design Systems in Wasm: One year on the bumpy road to the component model shows some of what is coming in the next 12 months
- and so much more ...
With over 30 sessions published, what should I focus on next?
I am not really interested in ...
- server-side compute usage of wasm yet - perhaps next time
- registry usage - they need to mature
- composition - yet - the componmemt model spec is intriguing, but too green
I did do a quick experiment with py2wasm on pi_digits.py and will complete it with some rough perf measurement. Initial test shows 10_000 digits of pi generated in ~1.6 secs. pi_digits.wasm is about 26MB. Interesting. But more work is needed.
As more runners adopt WASI 0.2 (threads, network, etc.) support, I would like to build something more real world. We will see.
For example, wasmer has support for a lot of extensions, but I do not believe they are implementing WASI 0.2/0.3; but rather their own WASIX extension set.
Also, I want to spend some more time with assemblyscript.
| Runner | Comments |
|---|---|
| wasmtime | The Byte Code Alliance runner written in Rust; uses the Cranelift code generator |
| wasmer | Written in Rust; no spec version mentioned but says implements WASIX, WASI and emscripten; supports the Single Pass, Cranelift and LLVM pluggable compilers |
| wazero | This is the runner of choice for most of the golang community. The main branch indicates support for WASM Core V1 and V2 specs; WASI preview 1 |
The different runners use different terminology to describe how wasm generation occurs.
Wasmtime uses the term code generator. And suggests it is currently implemented using the Cranelift code generator.
Wasmer uses the terms native backend in some places; and compiler in others. Wasmer documents their pluggable compilers as follows.
Pluggable compilers — A compiler is used by the engine to transform WebAssembly into executable code:
- wasmer-compiler-singlepass provides a fast compilation-time but an unoptimized runtime speed,
- wasmer-compiler-cranelift provides the right balance between compilation-time and runtime performance, useful for development,
- wasmer-compiler-llvm provides a deeply optimized executable code with the fastest runtime speed, ideal for production.
Wazero supports a wasm interpreter as well as AOT compilation via its so-called zero dependency optimizing compiler.