Europe/London
BlogFebruary 10, 2026

Wasm in 2026: What It's Actually Good For, and What It Still Isn't

Dubz
For about a decade, WebAssembly was the conference-talk technology. Near-native speed in the browser! Rust everywhere! And every demo was the same two things: Figma and a game engine. Impressive, and almost useless to me. I don't maintain a design tool or a game. I ship small products, and for years the honest answer to "should I use Wasm?" was no. That answer changed, and not because Wasm got exciting. It got boring, which is better. The core trick of Wasm is not speed for its own sake. It is shifting compute from a server you pay for, every month, per request, to a device the user already owns. If you process audio, transcode video, resize images in bulk, or run a heavy financial model, you have two options. You can run that on your infrastructure and pay for it forever. Or you can compile the processing to Wasm and let the user's browser do the work locally, at zero marginal cost to you. For a solo builder, that is not a performance optimization. It is a business model change. Free-tier features that would bankrupt you as server jobs become giveaways as client-side jobs. Three categories are consistently worth it now:
  • Media processing. Image resizing, audio filtering, video transcoding, entirely client-side. The libraries are mature and the fallback story (do it server-side for old browsers) is well understood.
  • Cryptography. Encrypt user data locally before it ever touches your network. When you can truthfully say "I never see your plaintext," that is a selling point, not just an architecture note.
  • Heavy calculators. Financial models, engineering tools, simulations. Anything where the user wants instant iteration without a round-trip to your API.
The talk of the last year is running small language models directly in the browser via Wasm and WebGPU. It works. I have run small models client-side and it is genuinely impressive. It is also, mostly, a demo. You are at the mercy of the user's memory, their device, and a WebGPU support picture that is still uneven. For privacy-critical or offline-critical features, it is worth shipping. For general generative features, a server-side API is still the pragmatic choice, and pretending otherwise is how you burn a week and ship nothing. DOM work. Wasm does not replace JavaScript for building interfaces, and every framework that claims otherwise adds complexity I don't want. Wasm is for the heavy lifting, not the scaffolding. The sign a technology has matured is when the interesting thing about it stops being the technology. Nobody writes breathless posts about gzip. Wasm in 2026 is heading the same way: a utility-belt tool for offloading compute, unremarkable when it's the right choice, expensive when it isn't. That is a compliment. The exciting version of Wasm was a decade of waiting. The boring version pays your hosting bill.
Share this post: