Missing the Point of WebAssembly

Original Article ↗ Hacker News Discussion ↗

WebAssembly’s role in the web stack is contested: some see it primarily as a way to build browser apps in languages other than JavaScript, while others argue its real promise lies in being a low-level, sandboxed bytecode for plugins, edge computing, and cross-platform binaries beyond the browser. Commenters debate its limitations in the browser today — especially the need to go through JavaScript for DOM access, tooling complexity, and large runtimes — alongside emerging features like Wasm GC and the component model that aim to improve interop and performance. There is also tension between the power and security of opaque, compiled modules and the loss of “view source” transparency that historically made the web easy to learn and hack on.

What WebAssembly Is “For”

  • One camp argues the main win today is writing web apps in languages other than JavaScript/TypeScript.
  • Others say that was already possible via compile-to-JS (asm.js, ClojureScript, GWT, etc.), so that alone is incremental.
  • The more “exciting” view sees WASM as a general, safe, portable compute/sandbox layer: plugins, edge compute, IoT, secure native deps, etc.

WASM vs JavaScript on the Web

  • Many developers want WASM to replace JS so they can use their preferred languages across client and server.
  • Others see JS as fine or even powerful, with problems more in ecosystem/tooling than the core language.
  • A recurring practical pattern: keep JS as “scaffolding” or glue and offload hot paths or heavy libraries to WASM.

DOM, Browser APIs, and Tooling

  • In browsers, WASM cannot directly use DOM or most web APIs; it must call JS “host functions” as shims.
  • With reference types and Wasm GC, passing opaque host references (e.g., DOM nodes) becomes easier and more efficient, but still requires glue.
  • A component model and WebAssembly Interface Types (WIT) are being developed to standardize richer interop, but progress is slow and complex.
  • Some complain about heavy toolchains, large language runtimes, and difficulty doing things like code-splitting and startup-time optimization.

Opacity, View‑Source, and Accessibility

  • Strong concern that WASM makes the web opaque: compiled binaries are harder to understand than HTML/JS, undermining “view source” culture and casual learning.
  • Others counter that minified JS is already opaque and that better tooling could expose WASM source similarly.
  • Canvas‑centric WASM apps risk poor accessibility (screen readers, text selection, international text layout) unless extra effort and libraries are used.

Comparisons to Other Bytecodes and Novelty

  • Some say WASM is “just another bytecode” like JVM/CLR and doesn’t justify the hype.
  • Others highlight differences: lower-level, language-agnostic, formally specified with machine-checked validation, strong sandboxing, minimal ambient capabilities.

Adoption, Use Cases, and Skepticism

  • Examples cited: complex web apps (design tools, Earth-like viewers, Unity games, C#/Blazor) already using WASM effectively.
  • Skeptics argue that after nearly a decade, WASM still lacks a clear, dominant “killer app” on the web (no direct DOM, awkward threading, lots of glue) and question whether a universal compute layer is necessary or wise.