Why WasmGC Is a Game‑Changer for Flutter and Kotlin Multiplatform on the Web

WebAssembly was originally designed to let low‑level languages such as C, C++, and Rust run efficiently in the browser by exposing only a linear memory model. Because the design favored simplicity and closeness to hardware, there was no built‑in concept of garbage collection (GC), and each language had to manage its own memory with malloc and free.

WasmGC marks a major milestone: with GC support, languages like Kotlin and Dart become fully native on WebAssembly.

As more managed languages (Java, Kotlin, Dart, Go, Python) were ported to Wasm, the community increasingly demanded GC. Before WasmGC, compiling Kotlin required bundling its entire runtime and GC into the Wasm module, inflating binary size and causing performance problems.

Specific issues without WasmGC:

The Wasm stack is not traversable, so the language runtime must maintain a costly “shadow stack” to track live objects, slowing execution and bloating code.

Separate GC domains between JavaScript and Wasm lead to reference‑cycle leaks unless developers manually break the cycles.

Introducing WasmGC allows Wasm code to reuse the host browser’s GC (V8, SpiderMonkey), eliminating the need for a custom GC algorithm or runtime.

Technically, WasmGC adds two core reference types— structref (reference to a struct) and anyref (reference to any host object, e.g., a JS object)—and a third, i31ref, optimized for small integers. It also introduces first‑class struct and array types, so compilers emit instructions like “new MyClass ” instead of manipulating raw byte offsets.

Because the browser now owns the lifetime of these objects, placement in young or old generations, marking strategies, or reference‑counting details are entirely handled by the engine (Chrome’s V8, Safari’s JavaScriptCore, etc.).

Browser support timeline:

2017 – WebAssembly MVP released, only linear memory.

2019 – WasmGC proposal started; community recognized that without GC, managed languages remain second‑class citizens.

2021‑2022 – Prototype implementations in Chrome V8 and Firefox; Dart and Kotlin teams contributed feedback.

April 2023 – Kotlin 1.8.20 adds experimental Wasm target based on WasmGC.

Oct/Nov 2023 – Chrome 119 ships WasmGC as the default (no flag required); Firefox 120 follows.

2024 – Safari adds WasmGC support; all three major browser engines (Blink, Gecko, WebKit) fully support it.

2025 – Non‑browser runtimes (Wasmtime, Node.js) begin adding GC support, opening server‑side and edge use cases.

Impact on Flutter and Kotlin Multiplatform (KMP):

Binary size drops dramatically because the language no longer bundles its own GC.

Startup time improves sharply.

Memory fragmentation and leak issues caused by separate GC domains are resolved.

Interoperability improves: Wasm can now hold a direct reference to a JS string or a JS object can hold a reference to a Wasm struct, eliminating costly memory copies.

Flutter has committed to Wasm as its primary web rendering path, positioning itself against JS frameworks like Vue and React. For KMP, Wasm becomes a key target for web deployment.

In summary, WasmGC does not invent a new GC algorithm; it elevates “GC‑managed object references” to first‑class citizens in the Wasm type system, allowing browsers to trace object graphs correctly. This enables native‑like performance, smaller bundles, faster startup, and seamless JS‑Wasm interop, ushering WebAssembly into a new era of mainstream adoption.