WASM Is the New CGI

Original Article ↗ Hacker News Discussion ↗

Claims that “WebAssembly is the new CGI” prompt a broader look at how WASM might reshape serverless computing, plugin systems, and web app architectures. Commenters compare WASM to older technologies like CGI, Java applets, Flash, and the JVM, debating whether it offers genuinely new capabilities—such as safer sandboxing, better portability, and predictable performance—or mainly repackages long‑standing ideas with a modern branding. Alongside this, there’s tension between visions of a WASM‑powered, serverless future and alternatives like “local‑first” apps, with concerns about complexity, browser bloat, and whether the benefits justify the added layers of abstraction.

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.