WASM GC isn't ready for realtime graphics

Original Article ↗ Hacker News Discussion ↗

Web developers are finding that WebAssembly’s new garbage-collected (Wasm GC) model still falls short for real‑time graphics and high‑intensity workloads, even though it works well for pure computation and business logic in languages like Java, C#, or Go. Key pain points include slow access patterns (e.g., to typed arrays), costly JS↔Wasm marshalling, and the difficulty of coordinating memory management across the JS and Wasm worlds without introducing stutter or leaks. Several commenters note that traditional linear‑memory Wasm with manual allocation or custom runtimes remains better suited for games and advanced graphics, while Wasm GC’s main win today is smaller bundles and safer, more convenient interop for non‑graphics use cases.

Perceived state of Wasm GC

  • Several commenters find it surprising anyone ships heavy apps on Wasm GC given current limitations, especially for realtime graphics.
  • Others argue it already works well for many use cases (business logic, computational code, LLM inference, vector stores), but not yet for 3D/“AAA” graphics.
  • The original article is criticized for having no quantitative benchmarks; some see the conclusions as somewhat “maximalist” without data.

Real‑world experiences and performance

  • Reports of significantly improved perceived latency in real apps when moving to Wasm GC, particularly for non-graphics workloads.
  • A major pain point: heavy use of regex and large object graphs crossing the JS/Wasm boundary can incur big conversion costs.
  • Google Sheets is cited as using Wasm GC successfully for Java logic.

Typed arrays, linear memory, and interop

  • Key limitation: GC-managed byte arrays cannot currently be exposed as Uint8Array views like linear memory can; they’re opaque heap objects to JS.
  • Some hope future Wasm GC revisions will allow direct, efficient views into GC-managed arrays.
  • Multiple linear memories and SharedArrayBuffer are mentioned as partial answers for interop and threading, but not a full solution.

GC, realtime graphics, and games

  • Debate over whether GC’d languages are suitable for high-intensity graphics:
    • One side: “no automatic memory management is ready” for strict realtime; successful engines minimize or work around GC.
    • Counterpoint: managed languages (e.g., C# in mainstream game engines) are widely used; the core issue here is Wasm GC’s current overhead, not GC in general.
  • Unity is noted as C# on top of a C++ engine; GC-related stutter is a known engineering concern.

DOM access and web APIs

  • Wasm GC is seen as improving correctness and bundle size by enabling shared GC and eliminating cross-heap cycles.
  • Direct DOM access from Wasm is possible today via JS shims, but still involves an FFI layer and marshalling.
  • Some argue true “first-class” Wasm DOM access would require a C-friendly, low-level DOM API, not just GC integration.
  • WebGPU/WebGL are considered usable but behind native APIs in performance and tooling; overhead of API calls and sandbox constraints remain concerns.

NaCl vs WebAssembly

  • NaCl/PNaCl are remembered as performant but browser-hostile: separate APIs, verification constraints, poor integration with DOM/JS.
  • Some argue tooling and performance might have been better with NaCl; others point out it would face similar GC/interop issues at scale.