Every time Figma renders a complex design instantly, or Google Sheets recalculates a huge spreadsheet without lag, or a Shopify store applies a custom checkout rule — you're using WebAssembly. You probably didn't know that, and that's kind of the point.
For about 25 years, the browser could really only run one language: JavaScript. That was fine for most things, but it meant the entire web was capped by what JavaScript is good at. And JavaScript, for all its reach, hits some hard walls — walls that used to force you into a native desktop app, a heavier backend, or a compromise.
WebAssembly (Wasm) is how the industry quietly got past those walls. I'm not going to write a deep technical explainer of what Wasm is — plenty of those exist. This is more useful: here are the seven real problems developers kept hitting, the wall each one represents, and how Wasm solves it — with the actual companies doing it in production right now. Because Wasm didn't get popular by being cool tech. It got adopted because it solves specific, expensive problems that had no good answer before.
Wall 1: "JavaScript is too slow for this."
The classic wall. JavaScript is fast enough for most app logic, but the moment you hit genuinely heavy computation — recalculating a massive spreadsheet, editing video, rendering 3D, crunching large datasets — it runs out of road. JS was never designed for that kind of raw number-crunching.
How Wasm gets past it: it runs at near-native speed for the hot path. You write the performance-critical part in a systems language (Rust, C++), compile it to Wasm, and it executes far faster than the JS equivalent.
Who's actually doing it: Google Sheets moved its calculation engine to WebAssembly and recalculates cells about twice as fast. Figma's entire high-performance design engine runs on Wasm — a production rewrite that millions of designers depend on daily. These are desktop-grade experiences running in a browser tab, which simply wasn't possible with JavaScript alone.
Wall 2: "I need to run untrusted code safely."
This is the underrated one, and honestly the real reason Wasm is exploding on the backend and edge. Sometimes you need to run code you didn't write and don't trust — a customer's custom logic, a third-party extension, a user-submitted script. With JavaScript, isolating that safely is genuinely hard, and the usual answer (a separate VM or container per tenant) is heavy and expensive.
How Wasm gets past it: Wasm runs in a tight sandbox by design. It can only touch what you explicitly hand it — no ambient access to the filesystem, network, or host. That makes running untrusted code fast and safe, without spinning up a whole VM for each one.
Who's actually doing it: Shopify executes merchants' custom checkout rules — compiled from Rust to Wasm — at the CDN edge, serving millions of users a day. Cloudflare runs thousands of customers' code as Wasm isolates, densely packed on shared infrastructure. Running strangers' code safely and cheaply is a genuinely new capability, not just "faster JavaScript."
Wall 3: "I keep rewriting the same logic for every platform."
You've got core business logic — validation rules, a pricing engine, a parser — and you need it to run in the browser, on the server, and at the edge. In a JavaScript world, that often means maintaining the same logic three times, in three places, drifting out of sync.
How Wasm gets past it: write the logic once, in one language, compile it to Wasm, and run the same module everywhere — browser, backend, CDN edge, even a plugin host. One implementation, one source of truth, many runtimes.
Who's actually doing it: this portability story is the biggest growth area in the whole ecosystem. Per CNCF survey data, over 70% of developers now use or evaluate Wasm outside the browser — precisely because "run the same code securely in any environment" is worth a lot when you're maintaining logic across web, mobile, and edge.
Wall 4: "I want to use this great library, but it's not written in JavaScript."
There's a mature, battle-tested native library that does exactly what you need — ffmpeg for video, SQLite for storage, a C++ image processor — but it doesn't run in the browser. Your options used to be grim: reimplement it in JavaScript (slow, buggy, years of work) or shove it behind a backend service.
How Wasm gets past it: compile the existing library to Wasm and run it directly, in the browser, no rewrite. Decades of hardened native code, suddenly available client-side.
Who's actually doing it: ffmpeg, SQLite, and analytical databases like DuckDB all run in the browser via Wasm today — DuckDB/MotherDuck lets you run real analytical queries over large datasets entirely client-side. Instead of reimplementing mature software in JS, you just bring it along.
Wall 5: "My serverless functions have brutal cold starts."
Serverless is great until the cold start. Spinning up a container to handle a request can take hundreds of milliseconds — a painful tax on latency-sensitive workloads, and a real problem at the edge where you want to respond instantly.
How Wasm gets past it: Wasm modules instantiate in microseconds, not the hundreds of milliseconds a container needs. They're tiny and start almost instantly, which makes them ideal for edge functions and high-density serverless.
Who's actually doing it: this is what makes edge-FaaS platforms viable — runtimes like Spin (Fermyon) and WasmEdge exist specifically to run Wasm functions at the edge with near-zero cold start. When your function boots in microseconds, "serverless at the edge" stops being a nice idea and becomes practical.
Wall 6: "I need a safe plugin system for my app."
You want users or third parties to extend your product — custom rules, integrations, effects — but you can't let their code run loose inside your application. Building a safe, language-flexible plugin system in JavaScript is a serious undertaking, and usually a leaky one.
How Wasm gets past it: Wasm's sandbox makes it a near-ideal plugin format. Extensions run isolated, can only use the capabilities you grant, and can be written in any language that compiles to Wasm — so your users aren't locked into one.
Who's actually doing it: Wasm plugin systems power extensibility in databases, proxies (Envoy uses Wasm for filters), developer tools, and edge platforms. "Let people extend my app without letting their code hurt me" is exactly the problem Wasm's isolation was built for.
Wall 7: "I want to run AI inference without a GPU backend."
You want to run a machine-learning model — for a feature, a classifier, a small LLM — but standing up dedicated GPU infrastructure, or round-tripping every request to a backend, is expensive, slow, and a privacy headache.
How Wasm gets past it: Wasm lets you run inference close to the user — in the browser or at the edge — without a dedicated inference server. The data often never leaves the device, latency drops, and you skip the backend round-trip.
Who's actually doing it: in February 2026, Cloudflare deployed Llama-3-8b models across 330+ global locations using Wasm-based isolates. Libraries like ONNX Runtime Web and TensorFlow.js now support Wasm backends, letting models run efficiently in-browser and at the edge without special hardware. AI inference is one of the fastest-emerging Wasm use cases for exactly these reasons.
Why this is all happening now
Wasm has been "almost ready" for years, so why is 2026 the tipping point? Because the ecosystem finally matured past the gaps that held it back:
- WASI Preview 2 stabilized the system interface, and WASI 0.3.0 (February 2026) added native async I/O — the last missing piece for real server applications handling concurrent connections.
- The Component Model let modules written in different languages actually interoperate cleanly.
-
Tooling got good —
wasm-pack,wasm-opt, and mature runtimes (Wasmtime, Spin, WasmEdge) made it approachable.
The result: Wasm crossed the line from "cool browser demo" to production infrastructure. It's not an experiment anymore — it's shipping in products millions of people use every day.
The honest part: should you use it?
Here's the reality check, because hype helps no one: most applications don't need WebAssembly, and that's the correct answer for them.
JavaScript still owns the DOM, UI, and the vast majority of app logic — and it's better for that. Wasm isn't a replacement; it's a complement you reach for at specific moments. And it comes with real costs: debugging is still rougher than native, binary size matters (a Go "hello world" can be ~2.5MB), and there's no automatic garbage-collection integration with JS — memory management across the boundary takes care.
So the rule is simple: reach for Wasm when you hit one of the seven walls above — a measured compute bottleneck, a need to run untrusted code, cross-platform logic to share, a native library to bring in, cold starts to kill, a plugin system to sandbox, or inference to run at the edge. Don't reach for it for ordinary UI or CRUD. Profile first. Adopt deliberately. The developers getting the most out of Wasm aren't the ones using it everywhere — they're the ones who recognize which wall they've hit and reach for the right tool.
The takeaway
WebAssembly didn't win by beating JavaScript. It won by doing the specific things JavaScript never could — quietly, inside products you already use, at companies you already trust.
You don't need to go learn it tomorrow. You just need to know it exists, and know the shape of the seven walls — so that the day you hit one, you recognize it, and you remember there's finally a good answer on the other side.
Have you shipped anything with Wasm — or hit a wall where you wish you had? I'm especially curious about the non-obvious ones: the untrusted-code and plugin use cases feel underrated to me. What was the problem that made you reach for it?
Sources & further reading: real-world examples and figures drawn from 2026 WebAssembly writeups and surveys — Google Sheets (2x recalc), Shopify edge checkout rules, Figma's Wasm engine, Cloudflare's Feb 2026 Llama-3-8b Wasm deployment across 330+ locations, DuckDB/MotherDuck in-browser analytics, WASI 0.3.0's async I/O (Feb 2026), and CNCF survey data (70%+ using/evaluating Wasm outside the browser; Chrome usage ~5.5% of page loads). This is a fast-moving ecosystem — treat specifics as reported-as-of-writing and check the primary sources for the latest.
Top comments (13)
Great post! I just want to add that yes, WASM is the default runner for inference in the browser, but the real gains you get come from running it on WebGPU.
Great addition, and an important clarification — you're right that I compressed those together. Wasm and WebGPU are doing two different jobs in browser inference: Wasm is the portable, runs-everywhere baseline (it'll work on anything, no special hardware assumed), but the serious performance for real model inference comes from WebGPU getting you actual GPU acceleration. The honest framing is that Wasm makes in-browser inference possible and portable, and WebGPU makes it fast — they're complements, not competitors, and a lot of the ONNX Runtime Web / TensorFlow.js setups will use a Wasm backend as the fallback and WebGPU as the fast path when it's available. So "Wasm for inference" is really "Wasm for reach, WebGPU for speed." Good catch — worth making explicit, because someone reading the piece and expecting native-GPU numbers from the Wasm path alone would be disappointed.
You can also look into what wasmer did with WASIX, it was their attempt at getting more functionality out of WASI, given it was a bit shallow vs POSIX. I've been really deep diving into it since the interviewing started at them, there's still a few holes, but they're not nearly as big as they used to be. Their sdk set is also quite decent.
The concept of WASM is definitely the future we've been wanting 'run anything, anywhere, at native speeds', in that respect, it's amazing! One of the projects I showcased, was a rust-based MCP server, that supports tools from all the major languages, using WASM and supports dynamic tool registration (no restarts needed) and an audit log for every tool call and full isolation for multi-tenancy. That's all stuff possible with WASM, impossible on Node.js.
That being said, WASM as a platform still needs ALOT of work... Take Wasmer for instance, distributed WASM runtimes across the globe, if the server near you goes down, you're directed to the next server, if 2 people on opposite sides, different servers, edit the same thing at the same time, they havent quite figured out CRDT for it yet (I also showcased it implemented to them). So it needs work... But in the age of AI, expect the WASM platform to grow fast and make up for the years it's behind.
WASIX is a great pointer — filling in the POSIX gaps WASI left shallow is exactly what's needed for the "run real server apps" story to hold, and it's good to hear from someone deep in it that the holes are shrinking. Your Rust MCP server is the perfect proof of the thesis: tools from any language, dynamic registration with no restarts, an audit log per tool call, full multi-tenant isolation — that combination genuinely is impossible on Node, and it's the untrusted-code + plugin walls made real. And your honesty about the gaps (the distributed-runtime CRDT problem you had to implement yourself) is the credible part — the platform is years behind where the concept promises, but you're right that AI is about to pour rocket fuel on closing that gap. Great data point from inside the ecosystem. 🤝
My current hiring assignment is porting pgrust to run in wasmer. Just about done with that. That's where I found alot of things that simply arent ready yet. Not too sure how deep you are into Rust, but unwind panics werent supported, they just aborted as a way to 'make it work' at the time, but I fixed that, so pgrust would actually function properly. A perfect example of how WASM works and the clean separation it brings. You can run pgrust, but can you call it complete, if it cant Error handle properly? That's the tiny holes in WASM as a standard that need filling, cuz an app that works isnt good enough, it has to function identical to native, else there'll be edge cases that break it and a broken web service isnt great... I think (theory, no proof) that their current setup where you can select a database during setup on Wasmer, runs the database outside of wasm, because a database is undeniably the most important part of an app to get right and rather than offering a 'partially right' version, they accepted that the platform needs more maturing first and instead left it running as a separate external service outside of their ephemeral wasm instances, to make sure it persists perfectly, every single time, cuz 1 slip up and it's business data lost/corrupted, not just 'oh the app crashed'.
That kinda makes me confident in where WASM is going, the people behind it know the boundary of what's experimental and what needs to be flawless. Cuz it just takes 1 bad app to make someone reject WASM for the next 5-10 years, so when it's advertised as working, it has to work flawlessly.
Porting pgrust into Wasmer is about the best stress-test of the platform's maturity you could pick, and the panic-unwind detail is the perfect example — an app that runs but aborts instead of unwinding isn't complete, because "works in the happy path" and "handles the error path identically to native" are different bars, and the gap between them is exactly where production breaks. That's the WASM-specific version of a theme I keep circling: working isn't the same as correct, and the edge cases are where the truth lives. Your read on why they run the database outside wasm is sharp and, I think, right — the maturity move is knowing which parts you're allowed to ship "mostly right" and which parts have to be flawless, and a database is squarely the second kind. "The app crashed" is recoverable; "the business data corrupted" ends you. And your last point is the real stakes: WASM only gets one reputation, so shipping the flawless-required parts before they're flawless would poison it for a decade. The fact that the people building it clearly know that boundary is the most reassuring thing in your whole comment. Genuinely great view from inside the work — thank you for it. 🤝
Really good 🤝, especially the point that Wasm is more useful when it solves a specific bottleneck rather than being treated as a replacement for JavaScript.
The browser-side use cases are particularly interesting. I've been working on client-side PDF processing recently, and Wasm makes a noticeable difference when you start dealing with parsing, document manipulation, and larger files without sending everything to a backend.
I also agree with the point about not using Wasm everywhere. The boundary between JavaScript for the UI and Wasm for the compute-heavy parts seems to be where it makes the most sense.
Client-side PDF processing is a perfect example of the pattern — parsing and manipulating large documents is exactly the compute-heavy, keep-it-off-the-backend case where Wasm earns its place, and doing it locally means the files never leave the user's machine, which is a privacy win on top of the speed. And you've landed on the boundary that actually works: JavaScript for the UI, Wasm for the heavy compute. That division is the whole thing — not "replace JS," but "hand JS the parts it's bad at." Thanks for the real-world data point.
How did you measure startup time across the two runtimes, and did the Wasm result include compilation?
Really very very nice!! ❤️🙂
Some comments may only be visible to logged-in visitors. Sign in to view all comments.