Making WebAssembly a first-class language on the Web

Original Article ↗ Hacker News Discussion ↗

Role of WebAssembly on the Web

  • Consensus that WebAssembly is valuable but currently niche: mostly used for “heavy” apps (Figma, Unity, Photoshop-style tools, emulators) rather than ordinary websites.
  • Several commenters argue that low overall usage doesn’t make it a “dud”; it’s similar to WebGL/Video—critical for some workloads, irrelevant for many.
  • Others see years of investment plus relatively low adoption as evidence it will remain second-class for typical web development.

JavaScript vs WebAssembly as Browser Abstractions

  • One side claims JS is the “right” abstraction: dynamic typing and an object/GC model match the evolving, object-graph nature of the DOM and web APIs. WASM’s linear memory and static typing are seen as an impedance mismatch.
  • Others counter that WASM’s sandbox and simplicity are better for untrusted code, that static typing doesn’t preclude compatible API evolution, and that different execution models can coexist (CPU vs GPU analogy).
  • Some argue the dominance of JS is historical and path-dependent, not inherent.

Component Model, DOM Access, and Performance

  • Strong interest in the WebAssembly Component Model and direct Web API/DOM bindings to remove JS “glue” and its overhead. Reported experiments show large overhead reductions for DOM-heavy patterns.
  • Skeptics see it as over-engineered for a narrow win (e.g., string marshalling), with limited benefit for APIs like WebGL/WebGPU where time is spent in the API implementation, not glue.
  • Concerns raised about complexity: concurrency semantics, feature detection, polyfills, API evolution, and the risk of simply shifting complexity instead of eliminating it.

Tooling and Developer Experience

  • Many note a steep “WASM cliff”: complex toolchains, generated shims, and dual-runtime mental models discourage adoption.
  • Calls for better, more integrated tooling so most developers never touch WIT or low-level specs; hope that normal toolchains will “just target WASM”.

Languages, GC, and Interop

  • GC integration is seen as crucial for Go/C#/Java-style languages. Current WASM GC is described as primitive (e.g., no interior pointers), complicating efficient runtimes and FFI.
  • Some report impressive performance parity between native and WASM in compute-heavy contexts.

Security, Obfuscation, and Platform Direction

  • Mixed views on security: some worry about new attack surface and opaque binaries in the browser; others argue WASM shares the hardened JS sandbox and has a smaller, more regular surface.
  • Concerns that pushing full app runtimes into the browser strengthens “browser as OS” and cloud lock-in; others see it as empowering web apps against mobile platform lockdown.