By WebAssembly 3.0 became a W3C standard in September 2025. Eight months later, coverage has mostly settled into two camps: breathless “Wasm is ready for everything!” takes and equally unhelpful “still not production-ready” dismissals. Both are wrong, and both will cause you problems. The real answer is a matrix — four flagship features, three deployment targets, and at least one landmine that will wreck your architecture if you step on it too early.
What Actually Shipped in WebAssembly 3.0
The Wasm 3.0 spec standardized nine features that had been languishing in the proposals list for years. Four of them are worth your attention right now: WasmGC, Memory64, exception handling, and Relaxed SIMD. The other five — tail calls, multiple memories, reference types, bulk memory ops, and JS String Builtins — are useful but less likely to change your architecture decisions today.
WasmGC: Deploy It Now
This one is fully ready. WasmGC lets a Wasm module declare typed struct and array heap objects that the host engine’s GC manages natively. Previously, every garbage-collected language targeting WebAssembly had to bundle its own GC runtime inside the module — adding 500 KB to 2 MB of overhead and introducing competing GC pauses.
In practice: Kotlin/Wasm binaries are 50-70% smaller than their Kotlin/JS equivalents. Dart/Wasm (Flutter) ships via WasmGC. TeaVM compiles Java to WasmGC for browser targets. Every major browser supports it — Chrome 119, Firefox 120, Safari 18.2 — and Wasmtime has full support on the server side.
If you’re shipping a Kotlin or Dart app to the browser and still targeting JS output, you’re leaving real performance on the table. The WasmGC toolchain is mature enough to stop treating it as experimental.
Memory64: Production-Ready Server-Side, a Landmine in the Browser
Memory64 replaces 32-bit address indexes with 64-bit, breaking the original 4 GB memory ceiling. For large datasets, in-memory databases, video processing pipelines, and ML inference over large models, this is a meaningful unlock.
Here’s the problem: “Memory64 is in WebAssembly 3.0” does not mean “Memory64 works in your user’s browser.” Chrome has it behind an origin trial flag. Firefox has it behind a flag. Safari doesn’t have it at all. Deploying a Memory64 module to a production web app today means your app silently fails for a significant portion of users.
Server-side is a different story. Wasmtime has full Memory64 support. If you’re running Wasm modules in a server-side runtime — Cloudflare Workers advanced, Fermyon Spin, or directly via Wasmtime — Memory64 is available and production-ready today. The browser story will catch up by Q4 2026 when Safari support is expected to land.
Exception Handling: A Quick Win
The old exception handling story in Wasm was ugly: C++ used setjmp/longjmp hacks, Rust had panic-unwind workarounds, and Java runtimes did creative things with the stack. WebAssembly 3.0 standardizes typed try, catch, throw, and rethrow instructions.
The result, per Emscripten’s documentation: C++ exception-using code compiled with the new path is “much smaller and faster.” All major browsers support it. Wasmtime supports it. This is one area where you can just upgrade your toolchain and benefit immediately — no feature detection required, no waiting for Safari.
Relaxed SIMD: Fast, But Test on Safari
Standard Wasm SIMD required identical results across all hardware — a reasonable correctness guarantee that blocked mapping instructions to native CPU ops with slightly different rounding behavior. Relaxed SIMD trades that guarantee for speed: 4-8× performance gains for image processing, audio DSP, and matrix operations. The Mandelbrot benchmark clocks a 2.65× speedup.
The tradeoff: results may vary slightly between Intel and ARM hardware. For image manipulation or ML inference that’s acceptable. For financial calculations where bit-for-bit determinism matters, it is not. Browser support: Chrome and Firefox in 2026. Safari still has it behind a flag. For Relaxed SIMD in production browser apps, you need feature detection and a fallback code path.
The Production Readiness Matrix
| Feature | Browser | Wasmtime | Node.js |
|---|---|---|---|
| WasmGC | Ready | Ready | Ready (v22+) |
| Memory64 | Flag / No Safari | Ready | Flag required |
| Exception Handling | Ready | Ready | Ready |
| Relaxed SIMD | Ready (no Safari) | Ready | Ready |
| Tail Calls | Ready | Ready | Ready |
The One Gap: WASI Threading
The most persistent objection to WebAssembly for backend microservices is real: WASI does not yet have standardized threading. Shared memory and atomic instructions exist at the Wasm level, but the WASI interface spec doesn’t expose multi-threaded system calls in a portable way. This is the piece that limits Wasm as a general-purpose backend runtime.
WASI 0.3 is targeting integration-ready by August 2026 and completion by November 2026. That release focuses on native async I/O — a major improvement — but threading is a separate proposal without a confirmed 2026 date. The honest timeline for backend microservices: 2027 is more realistic than 2026.
What’s production-ready now for server-side Wasm: edge functions (Cloudflare, Fastly, Fermyon), sandboxed plugin systems, and language-agnostic extension mechanisms via the Component Model. These use cases don’t require threading.
Your Checklist
- Shipping Kotlin or Dart to the browser: target WasmGC, stop using JS output
- Need more than 4 GB in a Wasm module: use Wasmtime, not a browser target, for now
- Using C++ or Rust with Wasm exceptions: upgrade Emscripten to get smaller, faster builds
- Compute-heavy work (image, audio, ML): add Relaxed SIMD with a Safari fallback
- Planning Wasm-based backend microservices: wait for WASI 0.3 and the threading proposal
WebAssembly 3.0 is not a “finally ready for everything” moment. It’s a “finally ready for the right things” moment. That distinction matters more than the version number.
