What happened to WebAssembly

Original Article ↗ Hacker News Discussion ↗

Expectations vs. Reality

  • Many commenters say early hype imagined WASM as a universal, cross‑platform compile target replacing JS and even containers; reality feels smaller: “Figma runs faster” and niche infra wins.
  • Several compare it to the JVM story: huge theoretical promise, but it settles into important, bounded roles rather than “holy grail” ubiquity.

WASM vs JavaScript (and asm.js)

  • Debate over how “groundbreaking” WASM is versus compiling to JS or asm.js; some call it “just an optimization,” others argue asm.js was a fragile hack and WASM is cleaner, faster to start, and more robust.
  • Benchmarks show mixed results: JS can beat WASM in some compute cases due to sophisticated JITs; others report 2–4x speedups in real apps (image editors, complex UIs, games).
  • Key technical arguments: deterministic integer types, SIMD, better load/store model, optional GC, and no mandatory JS‑style GC overhead.

Browser Integration & JS Replacement

  • Strong desire in part of the community for WASM to directly access the DOM and “replace JS”; others insist this was never a design goal.
  • Today most frameworks still drive the DOM via JS “glue” or virtual DOM layers, which is seen as a major limitation for building full apps and for performance.
  • Some fear full‑canvas or WASM‑only UIs would damage accessibility and make ad‑blocking/scraping harder.

WASI, Containers, and Server-Side

  • Mixed views on WASI as a container replacement: proponents like the sandbox and instant startup; critics say it’s a small, oddly renamed POSIX subset that doesn’t solve packaging, networking, or orchestration.
  • Friction noted around multiple WASI versions, component model churn, and lack of cross‑engine uniformity.

Tooling, Standards, and Ecosystem

  • Tooling is repeatedly called immature: debugging often “printf‑level,” DWARF support stagnant, C/C++ and Rust toolchains awkward, multithreading constrained by browser security headers.
  • Standards politics (WASI, component model, UTF‑8 vs UTF‑16, GC model, SIMD vs flexible vectors) are seen as slowing progress and creating fragmentation and bad blood.

Binary Size & Runtimes

  • Disagreement over WASM bundle size: some experience multi‑MB artifacts; others show kilobyte‑scale Rust/Go/TinyGo examples with careful optimization.
  • A recurring complaint: every WASM app must ship its own runtime/stdlib (ICU, TZDB, libc, language runtime), whereas JS gets these “for free” in the browser.

Where WASM Clearly Shines

  • Widely cited strengths:
    • Porting large native codebases (C/C++, Rust, Java, Go) to the browser with little change.
    • High‑performance media, games, graphics, numerical code, and emulators.
    • Safe plugin and sandboxed execution (e.g., edge functions, user-defined logic, smart contracts).
    • Hidden but critical infra in build tools, editors, libraries, and specific web apps.

Sentiment Summary

  • One camp sees WASM as a quiet success: ubiquitous in niches, great for sandboxed native code, doing exactly what it was designed for.
  • Another camp is disappointed: JS remains central, DOM access is indirect, WASI/container dreams are unfulfilled, tooling is rough, and hype about “replacing JS” or matching NaCl/native performance hasn’t materialized.