By ByteBot
WebAssembly 3.0’s specification landed on June 13, 2026, and the headline number is nine. Nine production features are now formally standardized — WasmGC, Memory64, exception handling, tail calls, 128-bit SIMD, multiple memories, typed function references, extended constant expressions, and branch hinting. Some of these have been shipping in browsers for months. The 3.0 spec makes them official, establishes browser compatibility baselines, and draws a line. There is Wasm before this, and there is Wasm after.
WasmGC: The One That Changes the Economics
Garbage collection is now a native Wasm feature, and the implications for managed-language developers are significant. Before WasmGC, a Java, Kotlin, Dart, or Scala compiler targeting Wasm had to bundle its own garbage collector inside the module. That meant shipping 2-4 MB of GC runtime with every application — before any business logic ran. With WasmGC, the browser engine manages allocation and collection using its own built-in GC. The module gets smaller. Startup gets faster. The browser does what it was already doing.
The numbers back this up. JetBrains shipped Compose for Web on Kotlin/Wasm in September 2025, and their benchmarks show it running nearly three times faster than an equivalent Kotlin/JS build in UI-heavy workloads. Flutter and Dart apps see 5-10x faster startup times with WasmGC compared to the older Wasm compilation path. All major browsers — including Safari — now support WasmGC. Kotlin/Wasm apps run across 100% of modern browsers. The binary size objection is gone. The startup time objection is gone.
This is not a niche developer concern. Java and Kotlin together power a significant share of enterprise and mobile development. Dart drives Flutter, which has a substantial web presence. WasmGC gives all three a credible, production-grade browser compilation target that did not exist before.
Memory64: The 4 GB Wall Is Gone
Memory64 gives Wasm modules 64-bit addressing. The old limit was 4 GB of addressable memory per module — which sounds like plenty until you are rendering a complex CAD drawing, processing a high-resolution medical image, or running a large language model inference pass in the browser. Photoshop Web and AutoCAD Web both run on Wasm today. Both have bumped against the 4 GB ceiling. Memory64 removes it. Browsers impose their own caps (typically 16 GB per tab), but that is a very different constraint than 4 GB total.
For Rust and C++ developers: wasm64 compilation targets are now viable in production. If your Wasm module processes large data sets and you have been artificially partitioning workloads around the 4 GB limit, that workaround is no longer necessary.
Exception Handling and SIMD: The Performance Pair
Native exception handling in Wasm 3.0 introduces first-class try/catch/throw primitives with the exnref value type. The previous approach — based on longjmp/setjmp in C, emulated exceptions in Emscripten — worked but extracted a performance cost. Wasmer’s benchmarks show 3-4x faster PHP execution with native exceptions. PHP Wasm, Ruby Wasm, and similar language-runtime-in-browser projects pick up this gain without any code changes.
Relaxed SIMD rounds out the performance story. The deterministic SIMD in Wasm 2.0 was conservative — it guaranteed identical results across platforms but left vectorization opportunities on the table. Relaxed SIMD allows wider vectorization for numerical workloads and ML inference. A new Deterministic Execution Mode is available when cross-platform reproducibility matters. ML inference in the browser (ONNX Runtime Web, TensorFlow.js) benefits most, along with audio processing and physics engines.
What Did Not Make It Into 3.0
Stack Switching — which would enable lightweight coroutine-style concurrency inside Wasm — is still a proposal. JavaScript Promise Integration (JSPI), which would make async interop between JS and Wasm substantially cleaner, is experimental in Chrome but not standardized. Source Phase Imports, which would allow Wasm modules to be imported like ES modules, is still in progress. These are not small omissions. Stack Switching matters for server-side Wasm workloads. JSPI matters for any Wasm code that needs to interoperate with async JavaScript. They are coming — but 3.0 is not the release that includes them.
Who Should Act Now
Rust and C++ developers targeting Wasm can use Wasm 3.0 features today — all nine are shipping in current browser versions. Java, Kotlin, and Dart developers should evaluate WasmGC compilation targets for web projects; the tooling is production-ready. Teams running compute-intensive browser apps that have hit the 4 GB memory limit should evaluate Memory64 migration. Everyone else: the spec release is a baseline to track, not an emergency. Wasm usage on the web is growing — 5.5% of Chrome page loads and rising — and the toolchain has finally caught up to the ambition. Read the official WebAssembly 3.0 specification for the full feature list.
