Skip to content
Blog

Try Flutter Web with WebAssembly Week: What Changed and How to Migrate

Flutter's WebAssembly Week put Wasm under a microscope: 2x faster frames, one command to opt in, and a clear path past legacy JS interop.

Published on • October 18, 2026

AI Assistant

From August 17 to 21, 2026, the Flutter team ran Try Flutter Web with WebAssembly Week — a focused push to get developers compiling their Flutter web apps to Wasm, with Dart and Flutter engineers triaging incoming issues in real time to unblock migrations. The timing is deliberate: the team wants WebAssembly to become the default compiler for Flutter Web, and ecosystem testing is the bottleneck. Here’s what the week was about and what you should actually do.

Where Wasm stands today

Dart’s WebAssembly support stabilized back in Flutter 3.22 (May 2024), pairing the Dart compiler with WebAssembly Garbage Collection (WasmGC). Since then it has quietly become production infrastructure:

  • Dart DevTools — a complex, highly interactive Flutter web app — has shipped Wasm-by-default since late 2024, and over 97% of DevTools users run it on Wasm.
  • The Flutter team’s analysis found that over 58% of existing Flutter web apps compile to WebAssembly with zero code changes.

That second number is the interesting one. If more than half of existing apps already build clean, the migration cost for the remaining projects is the only thing standing between the ecosystem and a Wasm default.

Why it’s faster

Wasm gains come from two places: the dart2wasm compiler and skwasm, which offloads canvas rasterization to a dedicated Web Worker, keeping the main browser thread free for input and UI. In the team’s benchmark run (Chrome 151, an M4 Pro MacBook Pro at a 60 Hz refresh cap, 200 animated churn nodes):

  • Frame times up to 2x faster: where JavaScript dropped to ~30 FPS (34.5 ms total frame time) under heavy widget-tree churn, Wasm held 60 FPS (17.4 ms).
  • Widget building up to 2.5x faster: 29.3 ms down to 11.4 ms, thanks to native WasmGC structures.
  • Over 3x smoother frame consistency: jitter cut from ±1.5 ms to ±0.5 ms, largely by eliminating GC pauses.
  • Bundle size barely moves: no more than 5% larger compressed over the wire.

You don’t have to take these numbers on faith — the team shipped an interactive comparison at flutter-wasm-compare.web.app with open source code, so you can benchmark on your own hardware.

Why JavaScript is still the default

If Wasm is faster and half of apps already build clean, why hasn’t the default flipped? The compiler team’s answer is a genuine chicken-and-egg problem: some pub.dev packages still depend on legacy JavaScript interop (dart:html or dart:js), which needs updating for Wasm compatibility. The default won’t change until more packages migrate; package authors often won’t prioritize the migration until developers opt in and ask for it. That’s exactly what WebAssembly Week was designed to break.

How to migrate

The mechanical part is small:

flutter upgrade          # land on the latest stable with current WasmGC fixes
flutter build web --wasm # compile your app with dart2wasm + skwasm

If it builds and runs, you’re done — report your wins so the team can track progress. If it doesn’t, the failure usually traces to dependencies rather than your code:

  • Replace dart:html and dart:js with package:web and dart:js_interop. This is the core requirement for Wasm compatibility; the Dart JS interop guide covers the migration pattern by pattern.
  • Check the Wasm docs for server headers. Running with WasmGC threads requires COEP: credentialless and COOP: same-origin response headers on your host; the WebAssembly on Flutter Web guide covers headers, debugging production builds, and runtime detection of Wasm support.
  • Use conditional imports where you must support both targets. Keep the JS-interop-dependent code path behind an import condition so the same app still builds for dart2js.

During the week, blockers could be filed on the Flutter Wasm feedback form for engineer triage, with results shared under #FlutterWasmWeek.

What this means going forward

The 2026 Flutter roadmap states the goal plainly: WebAssembly is intended to become the default compiler for Flutter Web, delivering native-quality experiences and performance. The roadmap also notes collaboration with community-led frameworks like Jaspr for developers who want a traditional DOM-based approach — Wasm becoming default doesn’t end the DOM story, it completes the canvas-rendered one.

For you, the practical sequence is simple:

  1. Run flutter build web --wasm on your production app today. If it works, you’re already ahead of the default flip.
  2. If it fails, audit your dependency tree for dart:html/dart:js usage and file issues (or PRs) upstream.
  3. Migrate your own interop code to package:web and dart:js_interop.
  4. Configure COEP/COOP headers on your host before you ship the Wasm build.

WebAssembly Week was a community-sized nudge toward a decision the framework has already made. The faster the ecosystem moves off legacy interop, the sooner --wasm stops being a flag and starts being the default.

Sources

flutter web webassembly dart