Skip to content

PATTERN Cited by 2 sources

Game-engine stack for web canvas

A three-language client+server split for browser applications whose canvas and rendering are performance-critical:

  1. C++ (or another native systems language) compiled to WebAssembly for the canvas, renderer, object graph, layout, physics/collisions — anywhere raw throughput, predictable memory, and no-GC-pauses matter.
  2. React + TypeScript (or another web-native UI framework) for the UI shell — menus, panels, modals, standard web-platform interactions.
  3. Rust (or another memory-safe systems language with better ergonomics than C++) on the server tier — real-time collaboration servers, multiplexer proxies, other tight-loop backends that justify a native language.

The choice is driven by workload fit, not language preference.

When to reach for it

  • You have (or can build) a mature performance-critical native codebase that can't reasonably be implemented in JavaScript — a 2D or 3D renderer, a physics engine, a DAW, a CAD kernel, a game engine, a live-data grid handling O(100k) rows.
  • Your UI still needs to be web-shaped — standard DOM widgets, keyboard shortcuts, clipboard integration, accessibility tree, deep-linking, progressive enhancement.
  • Your server tier has a tight-loop component (real-time collaboration, streaming, pubsub fanout) that justifies a native language over Node/Python/Ruby.

When it's overkill

  • Pure CRUD / document web apps — the WASM build toolchain, FFI boundary complexity, and ops story don't pay back unless the canvas is the hot path.
  • Small teams — three language runtimes means three debug stories, three hiring pools, three profilers. Figma could absorb it; a five-engineer startup probably can't.

Why the split

C++ → WASM for the canvas

"WebAssembly ... 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."

The explicit memory model (linear byte-addressable memory the language controls) matches how games and renderers already think. GC pauses that would ruin a 60 fps render loop never happen because WASM doesn't have one. Ahead-of-time compilation removes JIT warm-up on startup.

React + TypeScript for the UI

"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."

UI engineering needs a rich widget ecosystem, fast-iteration ergonomics, and native access to browser capabilities (DOM, accessibility tree, IME, focus management). All of those are where React+TS shines and where C++/WASM is explicitly painful.

Rust on the server

"Rust in our multiplayer server ... provides better developer ergonomics than C++."

Rust is the server-side analog to WASM's client story: native-language performance, explicit memory management, fewer footguns than C++.

Consequences

  • Two FFI boundaries to manage: JS ↔ WASM on the client, and whatever transport (WebSocket / HTTP / custom) between client and Rust server. Both need design, profiling, and versioning.
  • Three profilers, three debuggers, three build toolchains. Team must absorb the ops overhead.
  • Cross-boundary data-model discipline. Shared concepts (object tree, IDs, property bags) need canonical encodings so C++ canvas, TS UI, and Rust server agree on semantics. Figma's concepts/object-tree-document-model is one such shared substrate.

Canonical instance

Figma — canvas in C++/WASM, UI in React+TypeScript, multiplayer server in Rust. The canvas WASM migration cut load time 3× over the earlier asm.js era. The Rust rewrite of the multiplayer server was a migration from the prior Node.js-based one. Both are referenced from the 2026-04-21 game-engine-inspiration post as the current stack.

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

Seen in

Last updated · 200 distilled / 1,178 read