Build Browser Games with WASM, WebGPU, and Rust [2026]

High-fidelity browser games stopped being a novelty once WASM became a practical delivery target and WebGPU exposed a modern graphics API in the browser. The result is a setup that feels much closer to native engine architecture: Rust owns simulation and rendering logic, the browser supplies the sandbox and distribution layer, and the GPU path is finally capable enough for serious 2D and lightweight 3D work.

This tutorial builds the core of that stack with Rust, wgpu, and a browser-hosted canvas. The goal is not a full engine. It is the minimal structure you can grow into a real game: deterministic updates, WebGPU-backed rendering, and a deployment path that fits the web.

Takeaway

For browser games, the winning pattern is simple: keep gameplay state and timing in Rust, treat JavaScript as a thin host layer, and use WebGPU for rendering so your web build mirrors your native architecture as closely as possible.

Prerequisites

Rust toolchain installed and working.
The wasm32-unknown-unknown target added with rustup target add wasm32-unknown-unknown.
trunk or another WASM bundler to serve the app locally.
A current desktop browser with WebGPU support enabled.
Comfort with basic Rust ownership and Cargo layout.

If you want to clean or reindent snippets before dropping them into your own docs or demos, TechBytes' Code Formatter is a useful companion during iteration.

Step 1: Scaffold the project

Start with a binary crate and keep the browser entry point thin. Your Rust code should expose a single async startup function, while HTML only mounts a canvas.

[package]
name = "browser-game"
version = "0.1.0"
edition = "2021"

[dependencies]
wgpu = "*"
winit = "*"
pollster = "*"
bytemuck = { version = "*", features = ["derive"] }
wasm-bindgen = "*"
wasm-bindgen-futures = "*"
console_error_panic_hook = "*"

[target.'cfg(target_arch = "wasm32")'.dependencies]
web-sys = { version = "*", features = ["Window", "Document", "HtmlCanvasElement"] }

Create a minimal index.html that gives Rust a canvas to render into:

<!doctype html>
<html>
  <body style="margin:0;background:#08111b">
    <canvas id="game-canvas"></canvas>
    <script data-trunk src="main.rs"></script>
  </body>
</html>

The important design choice here is architectural, not cosmetic: Rust remains the system of record for timing, simulation, and rendering. JavaScript does not run game logic unless you explicitly need a browser-only bridge.

Step 2: Initialize WebGPU

Next, create a renderer that can request an adapter, open a device, and configure the swapchain surface for the browser canvas. In practice, this is the moment where web and native builds begin to converge around the same rendering API.

use wgpu::*;
use winit::{dpi::PhysicalSize, event_loop::EventLoop, window::WindowBuilder};

struct GpuState {
    surface: Surface,
    device: Device,
    queue: Queue,
    config: SurfaceConfiguration,
    size: PhysicalSize<u32>,
}

impl GpuState {
    async fn new(window: &winit::window::Window) -> Self {
        let size = window.inner_size();
        let instance = Instance::default();
        let surface = unsafe { instance.create_surface(window) }.unwrap();

        let adapter = instance
            .request_adapter(&RequestAdapterOptions {
                power_preference: PowerPreference::HighPerformance,
                compatible_surface: Some(&surface),
                force_fallback_adapter: false,
            })
            .await
            .expect("No suitable GPU adapter found");

        let (device, queue) = adapter
            .request_device(&DeviceDescriptor::default(), None)
            .await
            .expect("Failed to create device");

        let caps = surface.get_capabilities(&adapter);
        let format = caps.formats[0];

        let config = SurfaceConfiguration {
            usage: TextureUsages::RENDER_ATTACHMENT,
            format,
            width: size.width.max(1),
            height: size.height.max(1),
            present_mode: PresentMode::Fifo,
            alpha_mode: caps.alpha_modes[0],
            view_formats: vec![],
            desired_maximum_frame_latency: 2,
        };

        surface.configure(&device, &config);
        Self { surface, device, queue, config, size }
    }
}

Two choices matter for perceived quality. First, prefer HighPerformance when available. Second, keep presentation mode stable; Fifo is usually the least surprising option on the web.

Step 3: Build a fixed-step loop

Many browser game prototypes feel bad for the same reason: they tie simulation to render timing. That works until the tab stutters or the GPU load spikes. The fix is the same one used in native engines: run simulation at a fixed timestep, then interpolate render state between snapshots.

const DT: f32 = 1.0 / 60.0;

#[derive(Clone, Copy)]
struct Player {
    x: f32,
    y: f32,
    vx: f32,
    vy: f32,
}

struct Game {
    current: Player,
    previous: Player,
    accumulator: f32,
}

impl Game {
    fn update(&mut self, dt: f32, input_x: f32, input_y: f32) {
        self.previous = self.current;
        self.current.vx = input_x * 240.0;
        self.current.vy = input_y * 240.0;
        self.current.x += self.current.vx * dt;
        self.current.y += self.current.vy * dt;
    }

    fn frame(&mut self, frame_time: f32, input_x: f32, input_y: f32) {
        self.accumulator += frame_time.min(0.25);
        while self.accumulator >= DT {
            self.update(DT, input_x, input_y);
            self.accumulator -= DT;
        }
    }

    fn alpha(&self) -> f32 {
        self.accumulator / DT
    }
}

That interpolation value becomes the bridge between stable gameplay and smooth visuals. It is a small detail, but it is one of the highest ROI upgrades you can make for browser feel.

Step 4: Render high-fidelity frames

Once the loop is stable, render from an interpolated position instead of the raw simulation state. Even for a simple sprite or quad, this avoids visible jitter on inconsistent frame pacing.

fn lerp(a: f32, b: f32, t: f32) -> f32 {
    a + (b - a) * t
}

fn render(game: &Game, gpu: &mut GpuState) -> Result<(), wgpu::SurfaceError> {
    let output = gpu.surface.get_current_texture()?;
    let view = output.texture.create_view(&wgpu::TextureViewDescriptor::default());
    let mut encoder = gpu.device.create_command_encoder(&wgpu::CommandEncoderDescriptor {
        label: Some("main-encoder"),
    });

    let x = lerp(game.previous.x, game.current.x, game.alpha());
    let y = lerp(game.previous.y, game.current.y, game.alpha());

    {
        let _pass = encoder.begin_render_pass(&wgpu::RenderPassDescriptor {
            label: Some("color-pass"),
            color_attachments: &[Some(wgpu::RenderPassColorAttachment {
                view: &view,
                resolve_target: None,
                ops: wgpu::Operations {
                    load: wgpu::LoadOp::Clear(wgpu::Color {
                        r: 0.03,
                        g: 0.07,
                        b: 0.11,
                        a: 1.0,
                    }),
                    store: wgpu::StoreOp::Store,
                },
            })],
            depth_stencil_attachment: None,
            occlusion_query_set: None,
            timestamp_writes: None,
        });

        let _sprite_position = [x, y];
    }

    gpu.queue.submit(Some(encoder.finish()));
    output.present();
    Ok(())
}

In a production game, this is where you add the pieces that actually create fidelity: instance buffers, sprite atlases, signed-distance text, normal maps for 2D lighting, or compact 3D meshes. The browser is no longer the main limitation. Asset discipline and frame budgeting are.

A practical rule is to keep binary assets compressed, batch draw calls aggressively, and move per-frame allocations out of the hot path. Rust helps with the last part because it pushes you toward explicit lifetime and ownership decisions instead of hidden churn.

Verification and expected output

Run the app locally with your WASM bundler and open the served page in a WebGPU-capable browser.

rustup target add wasm32-unknown-unknown
cargo install trunk
trunk serve --open

Expected result:

A full-window canvas with a dark clear color.
No panic during adapter or device creation.
Smooth player motion when input changes, without visible jitter during minor frame spikes.
Stable rendering after resize events once you wire surface reconfiguration into your window handler.

If you inspect performance tools, the main win should be obvious: simulation remains steady at a fixed step while the renderer stays visually smooth between updates.

Troubleshooting top 3

1. The page loads, but the canvas is blank

This is usually a surface configuration or presentation issue. Confirm the canvas has a real size, the surface format came from get_capabilities, and your render pass clears to a visible color before you attempt any draw calls.

2. The browser reports that WebGPU is unavailable

That typically means you are testing on an unsupported browser build, in a restricted environment, or without the required runtime flags. Validate with a current desktop browser first before debugging your Rust code.

3. Movement feels uneven even though frame rate looks high

The common cause is mixing variable render delta into gameplay state. Keep simulation on a fixed timestep, clamp long frame times, and render from interpolated state only.

What's next

Once this foundation is in place, the next upgrades are straightforward. Add a texture atlas and instanced sprite pipeline for large scene counts. Introduce asset streaming so your initial page payload stays small. Split gameplay, render extraction, and GPU submission into separate phases so the codebase remains navigable as features grow.

If you are building toward a premium browser title, the broader lesson is architectural: the web build should not be a second-class port. With Rust, WASM, and WebGPU, you can keep one mental model across platforms and spend your time on content, latency, and polish instead of maintaining a throwaway browser stack.