WASM Is the New CGI

Original Article ↗ Hacker News Discussion ↗

WASM vs CGI / “New CGI” Claim

  • Many see the headline as misleading: CGI is “one process per request, stateless by default,” whereas WASM is a portable bytecode for a VM.
  • Defenders argue the analogy is about the model, not the CGI protocol: snapshotting and resuming WASM modules can give “fresh per-request processes” without high startup costs, akin to “CGI without the downsides” and “serverless without cold starts.”
  • Critics say this ignores long‑standing techniques for sharing state across requests and conflates execution model (CGI/serverless) with implementation tech (WASM, micro‑VMs).

WASM vs JVM, CLR, Flash, Applets, etc.

  • Some argue WASM is “just another bytecode,” reinventing the JVM/CLR/Flash era.
  • Counterpoints:
    • Ubiquity: virtually every modern browser ships a WASM runtime by default.
    • Openness and multi‑vendor standardization vs earlier proprietary plugins.
    • Design for near‑native performance, linear memory, simple verified bytecode, and small surface area.
    • Easier compilation for C/C++/Rust and other non‑GC languages.
  • Others note JVM/.NET also verify bytecode and supported many languages; they see WASM as mostly a slimmer, better‑modularized redo.

Security and Sandbox Model

  • Broad agreement that WASM is safer than old plugins mainly because:
    • It runs inside the browser sandbox with limited capabilities.
    • Memory and control flow are constrained and easily validated.
    • Access to OS/host APIs is explicitly granted by the host (capability model).
  • Caveats:
    • Bugs inside a WASM module (e.g., C++ buffer overflows) still exist; they’re just contained.
    • Browser/WASM sandbox escapes still occur, though they are rare and heavily scrutinized.

Serverless, Local‑First, and Architecture Trends

  • Some predict server‑side WASM will power future “serverless” platforms: lightweight isolation, fast cold starts, potentially even bare‑metal runtimes.
  • Others favor “local‑first” apps (heavy client logic, server mainly for sync) and see serverless as mostly a cloud‑billing strategy.
  • Disagreement on feasibility of local‑first for complex, centralized, or highly collaborative systems.

Developer Experience, Performance, and Practical Use

  • Enthusiasts:
    • Reuse existing native code in the browser or in plugins.
    • Predictable performance vs JS engine heuristics.
    • Potential evergreen server runtimes decoupled from specific language versions.
  • Skeptics:
    • Extra complexity vs just using JS or plain server‑rendered code.
    • Large WASM blobs, worse battery life on mobile, and tricky debugging and linking.
    • Tooling and component model still feel immature; DOM access requires JS or bindings.

Meta: Cycles and “Inner Platform Effect”

  • Several comments frame WASM and serverless as part of recurring cycles:
    • Fat vs thin clients, CGI → app servers → serverless, plugins → JS → WASM.
    • Concern that complex WASM platforms risk re‑implementing OS‑like stacks “poorly” on top of existing systems.