WebAssembly was supposed to replace JavaScript. That didn’t happen. What happened instead is more interesting, and more useful if you’re deciding what to build with.

WASM has become production infrastructure for a specific slice of problems. It found its lanes. The teams getting value from it are not the ones who bought the hype. They’re the ones who picked it for the two things it’s better at than everything else.

What the numbers actually show

The HTTP Archive 2025 data shows WebAssembly running on 0.35% of desktop sites. That sounds tiny. It’s not the right number to look at. Among the top 1,000 websites, adoption sits at 2%. Among all Chrome users, it grew from 4.5% to 5.5% of page loads year-over-year. Usage is concentrated where it matters: high-traffic, high-stakes deployments.

The distribution tells you what WASM is: an infrastructure layer, not an application layer. You are not building your next product in WASM. You are running specific compute inside a product built with something else.

Microsoft’s .NET and Blazor stack accounts for roughly 79% of WASM usage in browsers. That’s not a diverse ecosystem of experiments. It’s one framework that found a real use case (C# teams who want a web front-end without rewriting in JavaScript) and executed on it. WASM succeeds when it solves a concrete problem for a specific audience, not when developers reach for it because it’s theoretically fast.

The two lanes where it works

Edge compute and serverless functions is the first. Cloudflare Workers, Fastly Compute, Fermyon Spin: these platforms are WASM-native and running production traffic at scale. The reason is simple. WASM cold starts in the microsecond range (roughly 200 to 500 microseconds), compared to 500ms to 2 seconds for container cold starts. When you’re running stateless edge functions on every request, that gap matters. Fermyon’s edge platform handles 75 million requests per second on WASM. American Express built an internal FaaS platform on wasmCloud. These are not proofs-of-concept.

AI agent sandboxing is the second, and the less obvious one. When an AI agent needs to invoke tools or run untrusted code, whether from a plugin, generated mid-run, or from a third party, you need a sandbox that starts in microseconds, enforces strict capability limits, and runs identically across every environment. Containers don’t fit that pattern. WASM does. The portability-plus-sandboxing combination is why MCP servers are beginning to adopt WASM as the execution format for AI tool capabilities. WebAssembly 3.0, finalized in September 2025, formalized the garbage collection support that unlocks more language targets for this use case. WASI 0.3, which launched in February 2026, adds the async support (streams, futures) that server-side agent workloads need.

What WASM still doesn’t do

Threading is the gap that keeps WASM off the general-purpose backend roadmap. WASI has no native multi-threading model today. Databases, high-throughput parallel compute, anything that assumes multi-core: those workloads don’t fit. Threads are in the WASI 1.0 spec, expected late 2026 or early 2027, but until that ships, WASM is not a container replacement for real backend services. Three years of “almost ready” for the broad server-side case, and that hasn’t changed.

Build your API on containers. Build your edge functions and agent sandboxes on WASM. Don’t try to run a database-adjacent workload on WASM yet.

Where React Native sits

React Native and WebAssembly are solving different problems, but they meet at a specific intersection that most teams miss.

React Native’s story in 2026 is about native mobile performance from a JavaScript codebase. The 0.84 new architecture replaced the old async Bridge with JSI (JavaScript Interface), enabling synchronous JS-to-native calls. Fabric renderer targets 60fps animations. Hermes V1 cuts memory consumption by 30% over the previous default engine. Cold starts on the new architecture sit at around 120ms. Flutter edges it slightly on raw performance (90ms cold start, 62fps animation vs 58fps for React Native), but React Native holds roughly 35% of the cross-platform market compared to Flutter’s 46%, and Expo’s managed workflow has closed most of the developer experience gap.

The WASM connection to React Native is narrow but real: compute-heavy operations that JavaScript can’t run fast enough. Real-time image processing, AR pipelines, ML model inference at the client edge. These are workloads where you want native-speed compute called from a React Native context. Tools like Polygen make it possible to include WASM modules as native components in React Native apps, giving you a single compiled module that runs in both your React web app and your React Native mobile app. Write the hot path once in C, Rust, or another WASM-targeting language, compile it, call it from both contexts.

That works for a specific class of app. It’s not a general architecture recommendation. Most apps running on React Native don’t need WASM inside them. If you’re doing signal processing or computer vision on-device, it’s worth evaluating. If you’re building a SaaS product with a mobile companion, it’s premature complexity.

The actual decision tree

You don’t choose between WASM and React Native. They sit at different layers. React Native is an application runtime. WASM is a compute primitive. The question is whether your specific performance problem, on mobile or at the edge, is the kind that WASM’s sandboxed, portable, low-cold-start profile solves.

For most early-stage teams, WASM earns its place in two situations: you’re building edge functions that fire at request scale, or you’re building AI tooling that needs to run untrusted or generated code safely. Outside those two cases, the complexity cost outweighs the benefit.

WASM found its place. It took about five years longer than the hype said it would. The teams that ignored the hype and waited for the use case to show up clearly are the ones building on it sensibly now.

If you’re evaluating whether WASM or a different runtime belongs in your stack, talk to us.

Sources