WebAssembly GC Ships Everywhere, WASM Becomes a First-Class Application Platform

WebAssembly GC (WasmGC) has reached cross-browser support, marking the moment WebAssembly transitions from a C/C++/Rust compilation target to a general-purpose application platform. Languages with managed runtimes, Java, Kotlin, Dart, Go, OCaml, can now compile to WASM without shipping their own garbage collector.

Why WasmGC matters

Before WasmGC, languages with garbage collection had to compile their entire runtime (GC, memory manager, standard library) to WASM and ship it alongside application code. That meant:

• Large bundles, a "Hello World" in Java-on-WASM was hundreds of KB
• Slow GC, the compiled GC couldn't use the browser's native memory management
• Poor interop, WASM objects and JavaScript objects lived in separate worlds, requiring expensive marshaling

WasmGC gives WASM direct access to the browser's garbage collector. Managed language objects are now first-class citizens in the WASM heap.

What becomes practical

• Flutter Web without the bloat, Dart compiles to WasmGC, cutting Flutter web bundle sizes significantly
• Kotlin Multiplatform in the browser, Kotlin/Wasm targets WasmGC directly
• Java in the browser, for real, frameworks like Vaadin can now ship reasonable bundle sizes
• OCaml (Reason, ReScript), functional languages compile cleanly to WASM without a runtime tax

The performance picture

Approach	Bundle Size	Runtime Perf	JS Interop
WASM (no GC)	Small	Near-native	Marshaling cost
WASM (shipped GC)	Large (runtime)	Near-native	Marshaling cost
WasmGC	Small	Near-native	Direct reference sharing
JavaScript	Native	JIT-optimized	Native

The bottom line

WasmGC removes the last architectural reason to avoid WebAssembly for managed languages. If your language of choice has a WasmGC backend, you can now ship it to the browser at near-native speed without the runtime tax. The browser is now a truly language-agnostic application platform.