WASM beats Canvas, edges

A browser demo is putting hard numbers on a shift web developers have talked about for years: for particle-heavy visuals, WebAssembly plus WebGPU can outrun JavaScript on a 2D canvas by an order of magnitude or more. (developer.mozilla.org) WebAssembly is compiled code that runs in the browser at near-native speed, and WebGPU is the browser interface that sends graphics and compute work to the graphics processor instead of leaving it on the main JavaScript thread. MDN says WebGPU was built for both drawing and general-purpose GPU computation, while WebAssembly is designed to run alongside JavaScript rather than replace it. (developer.mozilla.org 1) (developer.mozilla.org 2) That division of labor is the point of the particle demo circulating this week. In the React example described in posts on X, a JavaScript Canvas 2D version started to struggle around 40,000 particles, while the WebGPU plus Wasm version kept running past 500,000 particles. (x.com) The “500k+ FPS” line attached to the demo appears to be a shorthand claim from the post, not a standard benchmark label used in browser documentation. WebGPU’s own documentation describes gains in lower JavaScript workload and support for compute-heavy tasks such as physics simulation and machine learning, which is the more grounded way to read the result. (x.com) (developer.chrome.com) (web.dev) The timing matters because WebGPU is no longer a Chrome-only experiment. Web.dev reported on November 25, 2025 that WebGPU is supported across Chrome, Edge, Firefox, and Safari, which turns these demos from niche experiments into something more teams can target in production. (web.dev) Browser makers are also framing WebGPU as a compute API, not just a prettier graphics layer. MDN says WebGPU has first-class support for general-purpose GPU computing, and Google’s Chrome team said the API cuts JavaScript workload and can deliver more than threefold gains for machine-learning inference. (developer.mozilla.org) (developer.chrome.com) The edge-computing side of the story is moving in the same direction. In a March 29, 2026 analysis, The New Stack reported that WebAssembly is outperforming containers at the edge in workloads that need lightweight code, millisecond latency, and fast rollout to many endpoints. (thenewstack.io) That article tied the shift to the WebAssembly component model, a standards effort meant to make Wasm modules easier to package, link, and call without exposing low-level internals. Fastly’s Luke Wagner said at Wasm I/O in Barcelona that broader adoption depends on making Wasm “just works” for developers and frameworks. (thenewstack.io) The browser and edge trends are not identical, but they reinforce each other. The same pitch shows up in both places: move heavy work out of slow, high-overhead paths, keep the code portable, and let the runtime use the hardware more directly. (developer.mozilla.org 1) (developer.mozilla.org 2) (thenewstack.io) The practical limit is that support is still uneven by operating system and device, even with major-browser coverage. MDN still labels WebGPU “limited availability,” and web.dev says support varies by browser version and platform, so teams still need feature detection and fallbacks. (developer.mozilla.org) (web.dev) What the demo shows, stripped of the hype, is simpler: the browser is becoming a place for serious compute again. When particle systems jump from tens of thousands to hundreds of thousands inside a web app, the old line between “native” and “front end” gets thinner. (x.com) (web.dev) (developer.mozilla.org)