WebAssembly: Yes, but for What?

Original Article ↗ Hacker News Discussion ↗

Native apps vs web and user experience

  • Several commenters prefer native mobile apps for most tasks; others deliberately avoid them and stick to browser apps.
  • Arguments for native: better integration with OS features (especially accessibility), potentially lower power/memory use.
  • Arguments for web: stronger sandboxing, easier inspection/modification (F12, ad blockers), multi-tab workflows, and extensions like Vimium.
  • Some view the web as the “last democratic platform,” contrasting it with app stores, “crapware,” and opaque notification/ads controls.

Where WebAssembly is useful today

  • Strong agreement that Wasm is good for:
    • Performance‑critical inner loops (e.g., Figma’s core, image/video processing, parts of Google Sheets, Photoshop, Prime Video).
    • Porting large native codebases (e.g., LibreOffice/ZetaOffice, SQLite, Doom, 8‑bit emulators).
    • Plugin/extension systems and untrusted code: fine‑grained sandboxing, no implicit I/O, revocable network access, and clear host–guest boundaries.
  • For typical UI-heavy web apps, many think JS/TS remains more practical; DOM-based UIs in Wasm are seen as painful.

Wasm beyond the browser (server, cloud, multi‑target)

  • Some see Wasm as a “universal, sandboxed VM” useful for:
    • Running customer code on servers or at the edge (wasmCloud, Cloudflare Workers, workflow engines).
    • Cross‑platform binaries (abstracting over CPU/OS; alternative to Docker/JVM, or to universal binaries).
    • Embedded/plugin scenarios (e.g., on ESP32) where isolation and resource limits matter.
  • Others are skeptical, seeing it as “reinventing the JVM/Docker,” often driven by JS/Web devs not wanting to learn other stacks.

Missing pieces, complexity, and standards friction

  • Complaints about slow, bureaucratic standardization: string interop, DOM access, Wasm exception handling, and shared-memory threading are seen as incomplete or fragmented.
  • DOM access from Wasm still requires JS “glue”; some argue browser APIs aren’t first-class in Wasm, limiting its appeal for general web apps.
  • WASI and the component model are promising but immature; different runtimes support different subsets, making portability hard.
  • Tooling pain points: Emscripten standalone builds, lack of consistent setjmp/longjmp or EH support, weak wasm32 library compatibility, especially in Rust’s async ecosystem.

Language choices and Rust

  • Debate over JS/TS vs other languages: JS is called “great for apps” by some and “unsafe/unergonomic scripting glue” by others.
  • Rust is widely cited as a strong Wasm target and “write once, bind everywhere” vehicle, though still considered niche compared to mainstream managed languages.
  • Some projects use Rust+Wasm merely as a packaging/interop layer, preferring direct native bindings when good options (e.g. PyO3) exist.

Real‑world project experiences

  • C#/Blazor-in-Wasm: benefits from shared C# across client/server and small teams, but suffers from large binaries, slow startup, and JS/DOM interop friction; server-side Blazor might have been a better fit.
  • A Rust+Wasm backend on Cloudflare Workers: author reports severe ecosystem friction (libraries not compiling to wasm32, Tokio incompatibilities), unclear standards, and runtime limitations (e.g., no time API), but values the clarity and discipline imposed by constraints.
  • Other SDKs (TypeScript, Go) successfully embed Rust/Wasm cores but require careful runtime pooling and manual bindings.