The Road to the WASM Component Model 1.0
3 days ago
- #WASI
- #WebAssembly
- #Component Model
- WASI P3 introduces native async support to WASI and Component Model, with focus on stable Component Model 1.0.
- Component Model defines type system, binary format, interface language, and calling conventions for Wasm binaries, while WASI provides standardized APIs for system resources.
- Relationship is like microkernel architecture: Component Model as foundational primitives, WASI as optional OS services on top.
- Five key areas for Component Model 1.0: ABI improvements (e.g., lazy ABI for zero-copy, multivalue returns), browser implementation path, easier implementation (simplified spec, C ABIs), ecosystem growth (documentation, tooling), and WIT expressivity gaps (e.g., optional imports, callbacks).
- ABI improvements aim for zero overhead on synchronous calls and include lazy ABI to replace cabi_realloc, with dependencies like LLVM support.
- Browser implementation strategy uses jco transpiled components for telemetry to motivate native support, with Mozilla and Chrome showing interest.
- Implementation ease involves simplifying spec and providing guest/host C ABIs via wit-bindgen.
- Ecosystem growth includes more documentation, language support, and tools like jco, wac, and debugging features.
- WIT enhancements planned include optional imports, callbacks, resource/function subtyping, and map types.
- Cooperative threads and stream splicing are in progress, with cooperative threads implemented at Component Model level.
- Toolchain view emphasizes coordination across dependencies like Rust, LLVM for feature releases.
- Community involvement encouraged via spec discussion, implementation, language toolchains, browser usage, and discussion on Bytecode Alliance Zulip.