WASM 2.0

Original Article ↗ Hacker News Discussion ↗

New 2.0 Features & Practical Speedups

  • SIMD: 128-bit fixed-width vectors (i8x16, i16x8, i32x4, i64x2, f32x4, f64x2) are seen as a big win for numerics, image/audio/video, ML, and crypto.
  • Anecdotes: people report 3–10x speedups over “straight” JS for pixel-heavy loops and string routines, and 4–16x over portable C in some string.h functions.
  • Multi-value returns, bulk memory ops, reference types, sign extension, and non-trapping conversions are welcomed as incremental but meaningful improvements.

SIMD Design Debate (128-bit vs Flexible Vectors)

  • Some argue fixed 128-bit SIMD is inherently non-portable-optimal and that a flexible/variable-width vector design (similar to ARM SVE, RISC‑V V) would have been cleaner and more future-proof.
  • Others counter that fixed-width SIMD is simpler, already covers most real-world usage (e.g., vec4/mat4x4), and “opportunistic” uses like small struct copies are easier with fixed widths.
  • Concern: hand-written 128-bit SIMD in Wasm may eventually underutilize wider hardware vector units.

Toolchains, Languages & ABIs

  • Rust/LLVM currently don’t exploit multi-value returns at the Wasm ABI level due to ABI compatibility choices; similar questions are raised for Clang.
  • Workarounds (packing multiple values into a larger integer) are used in other environments.
  • Experience with game jams and browser apps: Emscripten is described as powerful but bloated and brittle; some smaller languages (Odin, Zig, Go) have mixed but improving stories. TypeScript remains attractive for “one-language” stacks.

Wasm vs JavaScript / GPU

  • Skeptics claim Wasm mostly offers “just” speed and that JS (possibly with asm.js-like subsets or typed arrays) could suffice, or that work should go directly to WebGL/WebGPU.
  • Proponents respond that:
    • Wasm avoids unpredictable JS GC pauses and is better for sandboxing untrusted plugins.
    • For many compute-heavy workloads (computer vision, ML, physics, codecs), Wasm on CPU is simpler to deploy and can be faster than GPU due to overheads and model size.

Web vs Non-Web, DOM Access & “DOA” Claims

  • Some declare Wasm “dead on arrival” without direct DOM access and no JS shim. Others note:
    • Wasm is already in active, production use in browsers (e.g., libraries like ffmpeg, ImageMagick, SQLite, Figma-like engines).
    • The spec and community have always framed it as a general, platform-independent binary format, not just for the web; non-browser runtimes and “container-like” use cases are growing.
  • There are suggestions that a WASI-style DOM capability or “WASI DOM” could eventually rationalize DOM access for Wasm modules.

Runtimes, 2.0 Adoption & 3.0 Roadmap

  • Commenters say most major engines have effectively shipped 2.0 features for years; 2.0 is described as a bundling/marketing milestone.
  • A 3.0 draft spec already exists; features in 3.0 reportedly have at least two browser implementations but are less uniformly shipped than 2.0.
  • Some tooling (e.g., Wizard) is close to full 3.0 support, with a few features like memory64 and relaxed-SIMD still in progress.

Debugging, Instrumentation & Higher-Level Abstractions

  • Developers ask how to implement custom in-page debuggers and inspectors for Wasm-generated code.
  • Proposed approaches:
    • Bytecode rewriting to inject calls back into JS;
    • Engine-side instrumentation (where available) to avoid offset changes;
    • Self-hosted interpreters (e.g., wasm interpreters written in C/JS) for fine-grained control.
  • For richer types, the GC and component model proposals provide structs, arrays, enums, options, and results, but these are often “opaque” and ultimately grounded in integers/floats plus memory layouts.

Security & Constant-Time Concerns

  • Wasm’s sandbox model (no ambient access; all I/O via explicit imports) is cited as a strong security advantage, though in browsers most capabilities still come via JS or the host.
  • One perspective: in general-purpose settings, JS and Wasm should be viewed as comparably “safe,” with different tradeoffs (e.g., eval vs memory safety bugs).
  • A major concern is that the constant-time proposal for side-channel-resistant crypto has been marked inactive; until it’s revived, Wasm crypto remains exposed to timing attacks.

Spec Quality, Learning Resources & Miscellany

  • Runtime implementers praise the spec as unusually precise and well tooled, with a reference interpreter and robust conformance tests.
  • Educational material like “WebAssembly from the Ground Up” is mentioned for those wanting to learn by building a small compiler.
  • Naming “Wasm” vs “WASM” triggers extended bike-shedding; many prefer “Wasm” as a contraction-turned-word, analogous to “scuba” or “radar.”