WebAssembly Is Quietly Changing What Browsers Can Do
Wasm has moved past its gaming and CAD roots and is now running production tools like Photoshop and Figma at near-native speed.
A few years ago, if you heard about WebAssembly at all, it was probably attached to a demo: a game engine ported to the browser, a CAD viewer, something that existed mostly to prove the tech worked. That phase seems to be ending. Wasm is now shipping in every major browser, and it’s showing up in tools people actually use every day.
The clearest example is Photoshop’s web version, which leans on WebAssembly to get a notoriously heavy native application running inside a browser tab without falling over. Figma is doing something similar with its rendering engine — the part of the app responsible for drawing all those vectors and layers smoothly is compiled to Wasm rather than hand-written in JavaScript. Neither of these are toy projects. They’re signals that Wasm has crossed over from “interesting side technology” to “load-bearing infrastructure.”
Why this is happening now
The pitch for WebAssembly has always been simple: take code written in C++, Rust, or Go, compile it to a compact binary format, and run it in the browser sandbox at speeds much closer to native than anything JavaScript can offer. What’s changed isn’t the pitch — it’s that the tooling around it has matured enough that shipping Wasm in a real product doesn’t feel like an experiment anymore. Compilers, debugging support, and the surrounding ecosystem have all caught up to the point where teams building performance-sensitive web apps can reach for it without reinventing everything from scratch.
That matters because a huge amount of software still doesn’t have a good browser story. Anything CPU-heavy — image and video processing, CAD, scientific computing, complex rendering pipelines — has historically meant either shipping a native desktop app or accepting that the web version would be a compromised, slower cousin. Wasm chips away at that tradeoff. It doesn’t replace JavaScript, and it’s not meant to; it’s better thought of as a way to bring existing, battle-tested native codebases into the browser instead of rewriting them from scratch.
It’s also worth noting the momentum outside the mainstream browser too. Deno, the JavaScript/TypeScript runtime built by Node’s original creator, has been adding WebGPU support, which points at a broader trend: the browser and browser-adjacent runtimes are being treated as legitimate targets for genuinely demanding compute and graphics workloads, not just documents and forms.
None of this means every web app needs WebAssembly. Most don’t, and reaching for it when a normal JS bundle would do is just added complexity for no benefit. But for the specific category of software that needs raw performance — a big image editor, a design tool with a custom rendering engine, anything that used to require “just download the desktop app” — Wasm is turning into the default answer rather than the exotic one.
Worth watching over the next year: whether more mainstream productivity and creative tools follow Figma and Adobe’s lead, and whether WebGPU support spreads widely enough that Wasm plus GPU access becomes a standard combination rather than a cutting-edge one.