When Is WebAssembly Going to Get DOM Support?

Original Article ↗ Hacker News Discussion ↗

Expectations vs. reality for WebAssembly in browsers

  • Many commenters describe feeling “rug-pulled”: early messaging hinted at WASM as a first-class replacement for JS in the browser, but years later it still feels like a second-class citizen that must go through JS glue.
  • Some argue this narrative discourages long‑term investment and “smart people” from betting on the ecosystem. Others counter that WASM was never meant to be a full JS replacement, but a compute backend.

Why direct DOM support is hard and controversial

  • DOM APIs are defined via WebIDL but are deeply JS-centric: JS strings, objects/properties, promises, exceptions, GC, etc.
  • WASM only has numbers, linear memory, and now limited reference types; there is no native concept of JS strings or objects, so every DOM call implies marshalling and conversions.
  • A truly “direct” WASM DOM would probably require a new, low-level DOM API (or “syscall-like” layer) shared by JS and WASM—a massive multi‑year standardization and implementation effort browser vendors currently show little appetite for.
  • Some fear duplicating DOM surfaces (JS + WASM) would balloon complexity and attack surface.

Interop, reference types, and performance

  • Reference types and JSPI are seen as big steps that reduce copying and make calls cheaper, but the JS↔WASM boundary still penalizes DOM‑heavy workloads, especially with strings and complex objects.
  • For high‑frequency calls, people batch operations or restrict themselves to primitive types (ints/floats), similar to other FFI scenarios.
  • Tooling like wasm-bindgen, web-sys, Embind, and newer component-model efforts (e.g., Jco, WIT) help generate glue, but introduce their own complexity and aren’t yet browser‑native.

Where WASM shines today

  • Widely praised for:
    • Porting large C/C++/Rust engines (CAD, games, physics, GIS, simulators) where a JS rewrite is unrealistic.
    • Shared logic between backend and frontend, though the Rust/TS boundary is often “janky.”
    • Server‑side and “enterprise compute” use: lighter-weight, safer isolation compared to many Docker microservices; strong interest around WASI and the component model.

Diverging visions and ecosystem concerns

  • Some want WASM as a JS-free app platform with direct DOM, typed UIs, multithreading, and shared types front/back.
  • Others argue UI should stay JS-centric and WASM remain a performance module behind JS/DOM abstractions.
  • Historical comparisons to Java applets and Flash surface worries about repeating past plugin mistakes, but others note WASM’s much stricter sandbox and minimal default capabilities.