WebGPU and WASM now let Rust games hit near-native rendering and input paths in the browser. Build one step by step with code. Full breakdown.
Why WASM + WebGPU changes the browser game stack
Rust already compiles cleanly to WebAssembly, so the same game logic you would run on a desktop target can ship in the browser with a small runtime and predictable performance. The missing piece for years was a graphics path that matched native APIs. WebGPU fills that gap: compute and render pipelines, buffer management, and shader stages that map closely to modern GPU models instead of forcing everything through older canvas or WebGL abstractions.
Together they give you a near-native loop: compile game code to WASM for CPU work and input handling, then submit draw and compute work through WebGPU. You still pay for browser sandbox limits and async GPU scheduling, but the architecture looks like a real engine, not a toy demo bolted onto the DOM.
Project layout and the core loop
Start with a Rust crate that owns simulation, input state, and rendering commands. Keep platform glue thin: a small JS or Rust-wasm bridge creates the canvas, requests a WebGPU adapter and device, and forwards pointer, keyboard, and resize events into WASM. Your main loop should stay simple: read input, step simulation at a fixed or semi-fixed timestep, build GPU commands, submit, then present.
Separate pure game state from GPU resources. Entities, physics, and rules live in Rust structs that do not know about the browser. Buffers, textures, pipelines, and bind groups live in a renderer module that only receives what it needs for the current frame. That split keeps hot-reload of logic easier and makes it obvious when you are thrashing GPU memory versus doing honest simulation work.
Rendering and input paths that stay fast
- Upload only what changed: dynamic vertex or instance buffers for moving objects, static geometry kept resident.
- Batch draws by pipeline and material so you are not recreating bind groups every frame.
- Map input once per frame into a compact struct (axes, buttons, pointer delta) instead of sprinkling DOM callbacks through gameplay code.
- Use compute shaders for work that is parallel and data-heavy—particle updates, culling helpers—when the CPU path becomes the bottleneck.
Prefer a single command encoder per frame for the common path. Record clear, pass, and copy operations in order, then submit once. For input, normalize browser quirks (pointer lock, preventDefault on keys you own, high-DPI canvas sizing) at the edge so gameplay code sees stable units: world coordinates, not CSS pixels.
Build, ship, and iterate without fighting the toolchain
Target wasm32-unknown-unknown, generate JS bindings for the surface you expose (init, resize, frame, input), and serve the WASM module with the right MIME type and caching headers. Keep asset loading async: fetch textures and meshes, decode off the main thread when you can, then create GPU resources once data is ready. Fail visibly if the adapter or required features are missing; a clear “WebGPU not available” path is better than a blank canvas.
Iterate in small slices: a clear color and triangle, then a camera and mesh, then input-driven movement, then a real scene. Profile where frames go—simulation, buffer writes, or GPU pass cost—before adding systems. The win of this stack is not magic speed; it is one language for game logic, a modern GPU API in the browser, and a pipeline you can grow into a full game without rewriting the foundation.