Notes on writing Rust-based Wasm

Original Article ↗ Hacker News Discussion ↗

Title and scope confusion

  • Several readers expected notes on hand-writing Wasm, not Rust→Wasm with wasm-bindgen.
  • The submission title on HN was edited to add “Rust” for clarity.

Perceived role and adoption of Wasm

  • Some argue Wasm has become bloated and niche, drifting from its original “hot loop acceleration” promise toward a general sandbox/component model.
  • Others counter that it’s widely used in real products (design tools, CNCF ecosystem, ML in the browser, server-side sandboxing/plugins), so “niche” is overstated.
  • There’s disagreement: one side predicts Wasm will remain a small niche; another asks for evidence and notes that Wasm users are often not typical JS developers.

Web interop, DOM access, and JS glue

  • A recurring frustration is reliance on JS “shim” code for DOM/Web APIs, especially string conversions (UTF-8 vs UTF-16) and boundary overhead.
  • Some want direct DOM and web API access from Wasm to build “traditional” webpages without JS.
  • Others argue DOM is inherently slow and string-heavy; JS shims aren’t usually the true bottleneck.

Rust-centric tooling and bindings

  • Wasm is seen by some as “basically a Rust thing” today, especially around the Wasm Component Model and WASI components.
  • Complaints about wasm-bindgen: complexity, stagnation (with mention of recent renewed work), and bloat compared to nicer experiences like PyO3.
  • Multiple comments recommend avoiding automatic high-level bindings (Rust/C++ objects ↔ JS) in favor of C-style interfaces, batched calls, and plain data types.
  • Helper tools like tsify are cited as useful for Rust/TS type alignment.

Component Model debate

  • Proponents say the Wasm Component Model reduces N² glue complexity by standardizing type interop, improves dev experience, and can make Wasm a first-class web citizen (including potential direct web APIs).
  • Critics see it as overengineered (likened to old COM/CORBA), solving a problem OS ABIs already handle with simple numeric types and conventions.
  • There’s concern about adding complexity to browsers vs keeping it in toolchains; others reply that standardizing this layer is precisely the point.

GC languages and runtimes

  • Discussion notes emerging Wasm GC support and experimental languages, but also current drawbacks: copying overhead across the boundary, poor string handling, and no multithreading yet.
  • Some feel GC on Wasm is redundant in browsers (JS already exists) and inferior to mature JVM/CLR GCs outside the browser.
  • Others point to existing GC-language targets (Go, Java, C#, Blazor) that mostly ship their own GC in Wasm.