WASM 3.0 Completed

Original Article ↗ Hacker News Discussion ↗

WebAssembly 3.0 introduces major new capabilities—including 64‑bit memories, built‑in garbage collection, exceptions, and tail calls—that aim to make the platform more suitable for complex and managed-language workloads like Java, Kotlin, Dart, and Scheme. Commenters are optimistic about slimmer runtimes and better interop with host GCs, but note real trade‑offs: 64‑bit memory can be significantly slower due to lost bounds-checking tricks, and many popular languages (notably C# and Go) can’t yet fully exploit the new GC model. There is also frustration that, despite these advances and growing non‑browser use (WASI, plugins, sandboxing), WebAssembly in the browser still lacks direct DOM access, keeping most UI work dependent on JavaScript shims.

Memory64, Performance, and Limits

  • 64‑bit memories are widely seen as necessary for large apps (e.g. video editing, Figma‑scale documents, local LLMs), but several commenters highlight serious slowdowns vs 32‑bit.
  • Explanation: on 32‑bit memories engines can reserve a 4 GiB virtual region and let hardware enforce bounds via page faults; with 64‑bit memories they can’t, so explicit bounds checks become common and expensive.
  • Some suggest using multi‑memory (many 32‑bit memories) as a “segmented memory” workaround, but most consider this painful and poorly supported by languages.
  • There’s confusion over why masking to 33–34 bits isn’t enough; others clarify the spec’s requirement that OOB must always trap, which rules out simple wraparound tricks.

Garbage Collection and Managed Languages

  • Wasm GC introduces a separate managed heap with structs/arrays and low‑level, host‑implemented GC. It does not shrink or replace linear WebAssembly.Memory.
  • Intended benefits:
    • GC’d languages can reuse the browser’s collector instead of shipping their own.
    • Smaller modules, less duplicated GC logic, and the possibility of cross‑heap GC with JS (no more leaks from JS↔custom‑heap cycles).
  • Several languages already target Wasm GC (Java via a dedicated compiler, Kotlin, Dart, OCaml, Scheme/CL projects). C#, Go, Python, Ruby, .NET are not ready yet; their runtimes rely on features Wasm GC doesn’t (yet) model well.
  • Debate:
    • Pro: shared GC reduces code size, complexity, and enables sharing JS/DOM objects safely.
    • Con: allocator strategies are language‑specific; embedded targets may suffer; mature runtimes with highly tuned GCs may gain little.

Exceptions, Tail Calls, and Advanced Control Flow

  • Native exception handling and tail calls are welcomed, especially for Scheme and similar languages that relied on CPS or heavy tricks before.
  • Some Lisp/Scheme folks discuss using Wasm exceptions as low‑level building blocks for condition systems and continuations; restartable exceptions per se still require higher‑level support.
  • C++ exceptions in the browser are expected to become more practical with real EH opcodes.

DOM Access, Front‑End Development, and WASM’s Scope

  • Large, contentious thread on “why still no direct DOM from Wasm?”:
    • One camp argues Wasm is a “toy” until it can drive the DOM directly and let people write full SPAs in Rust/Go/etc. without JS glue.
    • Others respond that DOM access is a host concern, not core Wasm; today you call JS APIs from Wasm via shims, which is fast enough in many cases, with string marshalling often the real cost.
    • Browser vendors are reluctant to re‑spec the DOM for a second ABI; security surface and complexity are cited as blockers.
  • Rust and Dart ecosystems already expose DOM APIs via generated bindings; higher‑level Rust frameworks (e.g. virtual‑DOM or fine‑grained reactivity) hide JS almost completely, though some overhead remains.
  • Consensus: true “native” DOM for Wasm is unlikely soon; component model + WIT + Wasm GC may eventually enable cleaner host APIs, but timeline and shape are unclear.

Use Cases: Heavy Web Apps, Plugins, Embedded

  • Many comments list real present‑day uses: complex CAD in the browser, 3D modeling engines, Envoy plugins, terminal plugins, Wasm outside browsers (WASI, sandboxed plugins, “lightweight cloud”).
  • Some push back that video editors and similar tools “don’t belong in a document browser”; others argue the browser has effectively become a cross‑platform OS and Wasm is its safer “native code.”
  • For embedded and microcontrollers, the 64 KiB page size is a pain; a “custom page sizes” proposal exists and has partial implementation, but didn’t make 3.0.

Tooling, Runtimes, and Spec Evolution

  • Experience building compilers directly to Wasm is mixed: the core instruction set is liked, but Binaryen’s JS API and WASI docs are criticized as under‑documented; some prefer Rust‑based tools (wasm-tools, custom IR + emitters).
  • Wasm 3.0 is additive: older modules keep working; engines like wasmtime and others already support most features (often behind flags).
  • The component model is clarified as outside the core 3.0 spec: it’s an extra container format and linking/interface layer that can be implemented on top of existing engines without browser changes.