WASM 3.0 Completed

Original Article ↗ Hacker News Discussion ↗

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.