Skip to content

CONCEPT Cited by 2 sources

WebAssembly

WebAssembly (often WASM) is a W3C-standardized binary instruction format for a stack-based virtual machine, designed as a portable compilation target for high-level languages (C, C++, Rust, …) that can run at near-native speed in browsers, on servers, and in other embedded runtimes. Distinguishing properties:

  • Efficient, explicit memory model — a linear byte-addressable memory that the compiled language controls directly (no GC required). Well-suited to languages written against manual memory management, including game engines and graphics cores.
  • Sandboxed by default — runs inside the host VM's isolation boundary; no direct OS access, which is why it's safe to ship to browsers.
  • Compiled ahead of time — the bytecode is already compiled, so startup time beats JavaScript JIT warm-up for large codebases.
  • Language-agnostic — a Rust program, a C++ codebase, and a Go program all produce interchangeable .wasm modules.

The combination makes WASM the canonical target when you want a performance-critical native codebase (rendering, game logic, crypto, parsing, simulation) to run inside a browser without rewriting in JavaScript.

Figma as a canonical WASM-in-production instance

Figma's client is a state-of-the-art 2D graphics/rendering engine written in C++ compiled to WebAssembly, with a React + TypeScript UI layer sitting on top. The 2017 migration from asm.js to WebAssembly cut Figma's load time by 3×.

Rationale the post makes explicit: "C++ ... is widely used in game engines for its efficiency and flexibility in memory management; that's exactly what makes it well-suited for high performance, real-time applications." WASM brings those C++ properties to the browser.

The workload split is intentional and well-formed (patterns/game-engine-stack-for-web-canvas):

  • WASM (via C++) — canvas, rendering, object graph, layout, collision detection, performance-critical paths.
  • JavaScript (via React+TypeScript) — UI, menus, panels, standard web-platform interactions, developer ergonomics.

"C++ does not come with great libraries for delightful and responsive user interface engineering, so we opted to write our UI layer in React and TypeScript instead."

(Source: sources/2026-04-21-figma-how-figma-draws-inspiration-from-the-gaming-world)

Other WASM instances in this wiki

  • concepts/wasm-git-server — Cloudflare Artifacts runs a WASM-compiled Git server inside a Durable Object to terminate Git protocol at the edge.
  • JavaScript runtimes use WASM as the compilation target for native extensions and cross-language polyglot runtimes.

When WASM pays off

  • You already have a mature performance-critical native codebase you don't want to port to JS.
  • Your workload has predictable memory behavior where GC pauses would dominate tail latency.
  • You need deterministic startup without JIT warm-up overhead.
  • You need to sandbox foreign code (WASM's isolation guarantees are stronger than running eval).

When WASM doesn't

  • DOM-heavy interaction — WASM can't touch the DOM directly; every DOM mutation crosses a JS ↔ WASM boundary. React+TS is still the right tool for UI shells.
  • Small codebases — the overhead of the JS ↔ WASM FFI + the larger build toolchain outweighs the perf gain for small feature-sized modules.

Seen in

Last updated · 200 distilled / 1,178 read