WebAssembly 3.0 with Andreas Rossberg

What It Covers

Andreas Rossberg, WebAssembly architect and former Google V8 team member, explores the evolution from version 1.0 through the groundbreaking 3.0 specification. The discussion covers garbage collection integration, multi-language interoperability, reference types, tail calls, and how WebAssembly expanded beyond browser compilation targets into edge computing, embedded systems, blockchain platforms, and deterministic execution environments requiring formal verification.

Key Questions Answered

• •WebAssembly 1.0 Design Philosophy: The initial release targeted existing ASM.JS users with minimal features - four numeric data types, linear byte array memory, and function pointers. This intentionally limited scope enabled quick adoption for C, C++, and Rust codebases while leaving deliberate gaps for multiple values, multiple tables, and multiple memories to be added in future versions without breaking compatibility.
• •Garbage Collection Architecture: Version 3.0 introduces low-level GC supporting only structs and arrays, not high-level objects like Java VM. Languages must map runtime data structures to these primitives, similar to native code compilation. The implementation leverages existing JavaScript garbage collectors in browsers, adding zero overhead for applications that don't use GC features, following the pay-as-you-go principle.
• •Performance Characteristics: WebAssembly excels at numeric computation with near-native performance through ahead-of-time compilation. JavaScript can outperform WebAssembly in dynamic scenarios due to runtime profiling and recompilation. Applications focused primarily on DOM manipulation gain minimal benefit from WebAssembly compilation. The calling overhead between WebAssembly and JavaScript is dominated by actual DOM work, not the boundary crossing itself.
• •Non-Web Use Cases: Edge computing platforms like Fastly, embedded systems at Siemens, and blockchain implementations adopt WebAssembly for three primary reasons - portability across hardware without rebuilding toolchains, strict sandboxing without ambient capabilities, and deterministic execution. The 3.0 deterministic profile ensures identical results across replicated computation environments by eliminating all sources of non-determinism beyond intentional concurrency.
• •Component Model Development: This separate specification layer defines language-agnostic high-level types and advanced module systems for cross-language interoperability. Unlike bare WebAssembly's hardware-like ABI requirements, the component model provides shared-nothing concurrency and standardized interfaces. Work progresses on defining a C ABI for WebAssembly and WASI libraries for operating system abstractions, enabling portable module composition without knowing entire system implementations.
• •Stack Switching via Continuations: The next major feature implements delimited continuations based on effect handlers, enabling efficient compilation of async/await, generators, and green threads. Current workarounds include expensive CPS transformations, trampolining through JavaScript, or brittle manual techniques. Effect handlers allow modular composition of multiple control effects without interference, letting generators suspend entire threads without knowing about thread scheduling logic.