WASM + WebGPU: Risks and Benefits

1. Why combine WASM and WebGPU

WebAssembly and WebGPU solve two different bottlenecks. WASM replaces slow, JIT-unpredictable JavaScript number-crunching (collision detection, rigid-body solvers, spatial hashing, cloth constraint solving) with a compact bytecode that runs at 1.3–3× the speed of hand-tuned JS and with far more consistent frame times — no GC pauses in hot loops written in Rust or C++ with manual memory management. WebGPU replaces WebGL's fragment-shader-only compute tricks (encoding data into textures to fake general-purpose GPU work) with real compute shaders, storage buffers, and explicit synchronization.

Neither technology alone solves the whole problem for a serious simulation. A cloth solver needs a CPU-side broad-phase collision pass (irregular control flow, hard to parallelize on GPU) and a GPU-side mass particle update (embarrassingly parallel, thousands of vertices per frame). Splitting the work along this exact fault line — CPU-friendly logic in WASM, GPU-friendly math in WGSL compute — is the pattern this article calls the "hybrid engine".

2. Reference architecture: CPU core + GPU compute

A typical hybrid simulation loop keeps three buffers alive: the WASM linear memory (particle positions/velocities as a flat Float32Array), a GPU storage buffer mirroring the same layout, and a small JS glue layer that copies between them only once per frame — never per particle.

class HybridSimulation {
  async init() {
    // 1. Instantiate the WASM module (Rust/C++ compiled solver)
    const { instance } = await WebAssembly.instantiateStreaming(
      fetch('solver.wasm'), { env: this.importObject() }
    );
    this.wasm = instance.exports;
    this.particlesPtr = this.wasm.alloc_particles(100000);

    // 2. Acquire WebGPU device + a storage buffer of the same size
    const adapter = await navigator.gpu.requestAdapter();
    this.device = await adapter.requestDevice();
    this.gpuBuffer = this.device.createBuffer({
      size: 100000 * 4 * 4, // vec4 per particle
      usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST,
    });
  }

  step(dt) {
    // CPU: constraint solving, broad-phase collision, contacts (irregular)
    this.wasm.solve_constraints(this.particlesPtr, dt);

    // One copy per frame: WASM linear memory → GPU staging
    const view = new Float32Array(
      this.wasm.memory.buffer, this.particlesPtr, 100000 * 4
    );
    this.device.queue.writeBuffer(this.gpuBuffer, 0, view);

    // GPU: mass-parallel integration + rendering (regular, embarrassingly parallel)
    this.dispatchComputePass();
  }
}

The key discipline: WASM owns the irregular, branch-heavy logic; WGSL compute owns the regular, data-parallel math. The JS glue layer does exactly one buffer upload per frame, not per object.

3. The memory boundary: linear memory vs GPU buffers

WASM's linear memory is a single contiguous ArrayBuffer, directly readable from JS with zero marshalling — this is why the WASM↔JS boundary is cheap compared to, say, calling into a native addon. The JS↔GPU boundary is a different story: queue.writeBuffer triggers a driver-level copy from CPU RAM to VRAM (or a shared-memory fast path on integrated GPUs), and reading data back (mapAsync) is asynchronous and can stall a frame if used carelessly.

Avoiding round-trips

The biggest performance killer in hybrid engines is a CPU→GPU→CPU round-trip inside the frame (e.g. running physics on GPU, then reading results back into WASM for collision response). Where possible, keep the entire per-frame dependency chain on one side: either GPU compute feeds GPU rendering directly (no readback), or WASM computes everything and only the final vertex buffer goes to the GPU once.

4. WebGPU browser support and fallbacks

WebGPU shipped by default in Chrome/Edge (2023) and Firefox and Safari followed with their own timelines through 2024–2025; coverage is now broad on desktop but still uneven on some mobile browsers and older Safari versions. Any production simulation needs a WebGL2 fallback path, which means either maintaining two render backends or using an abstraction library that compiles WGSL-like code down to both targets.

5. Benchmarks: WASM vs JS vs native

Numbers vary a lot by workload, but a consistent pattern shows up across published benchmarks for numeric, branch-light code (SIMD-friendly particle integration, matrix math): WASM lands at roughly 50–80% of native C++ speed, and 1.5–4× faster than equivalent hot-loop JavaScript, mostly because it avoids type deoptimization and has predictable memory layout. For branch-heavy code (tree traversal, BVH construction) the gap to native widens, since WASM's non-inlined function-call and bounds-checked memory access overhead matters more.

The takeaway: WASM is not "free native speed" — it is a large, reliable upgrade over JS for numeric code, with SIMD128 narrowing the gap to native further. Whether it is worth the added build complexity depends on whether the numeric core is actually the bottleneck; profile first.

6. Common pitfalls

7. When the combo is worth it

Not every simulation needs both technologies. A small particle demo with a few thousand points runs fine in plain JS + WebGL. The hybrid WASM+WebGPU architecture earns its complexity when at least two of these are true: the CPU-side logic is a genuine bottleneck (profiled, not assumed), the workload has a large embarrassingly-parallel GPU component that benefits from real compute shaders, and the project can afford to maintain a WebGL2 fallback for the ~10–20% of visitors on browsers without WebGPU.

For MySimulator's own heavier demos — large N-body systems, cloth with tens of thousands of constraints, SPH fluids — this is exactly the shape of the problem: WASM handles the solver and spatial structures, WebGPU compute handles the mass-parallel integration and rendering pass.