WASM GC isn't ready for realtime graphics

Original Article ↗ Hacker News Discussion ↗

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.