Stateful Hot Reload on Flutter Web Is On by Default

Hot reload is Flutter’s signature developer-experience feature — and for years, web was the exception. That changed in Flutter 3.35, when stateful hot reload on the web became enabled by default.

Source: What’s new in Flutter 3.35, The Flutter Blog, Aug 14, 2025.

What changed

Previously you had to opt in with the --web-experimental-hot-reload flag. As of 3.35, running your Flutter web app in development mode gives you hot reload out of the box — from the command line, your IDE, or your coding agent.

The flag situation:

• --web-experimental-hot-reload is no longer necessary; remove it from launch configs.
• If hot reload breaks your specific environment, temporarily disable it with --no-web-experimental-hot-reload.
• The team plans to remove the ability to disable it entirely in a future release.

Issue reports from the experimental phase drove real improvements: the Dart and Flutter web teams focused on both the performance of hot-reloaded code and the breadth of code changes that successfully reload.

Why stateful matters on web

Plain hot reload re-runs the top-level of your program and rebuilds widget state from scratch. Stateful hot reload preserves the values of your fields and the current element tree, so your app doesn’t reset to its initial state every time you tweak a build method. On a web app with form input, scroll position, or a half-finished checkout flow on screen, that’s the difference between iterating and restarting.

The goal stated in the release notes is a seamless and consistent hot reload experience across all platforms — mobile, desktop, and web behaving the same way.

Getting it working

Nothing exotic is required:

flutter run -d chrome

Edit your Dart code, save, and the browser updates in place. Active work at the time of the release extended this to -d web-server as well, so server-driven development environments get the same treatment.

If reload silently fails or misbehaves, the Dart team asks for bugs via the web hot reload issue template, and the hot reload on the web documentation covers environment-specific setup.

What else shipped in 3.35

Web hot reload was the headline, but the release carried more relevant to web developers:

• Wasm dry runs — every JS build now performs a Wasm compilation check and prints readiness warnings (--(no-)wasm-dry-run), preparing the ecosystem for Wasm becoming the default target.
• Dart & Flutter MCP Server on stable — AI coding assistants can inspect the live widget tree, fix RenderFlex overflows, manage pubspec.yaml dependencies, and self-correct analysis errors.
• Widget Previews (experimental) — preview widgets in isolation across themes, screen sizes, and text scales without launching the full app.
• Analysis server speedups — dart analyze, dart fix, and dart language-server now run an AOT-compiled analysis server snapshot; some analysis runs got nearly 50% faster.
• Accessibility gains on web — semantics locales for screen readers, SemanticsLabelBuilder, and SliverEnsureSemantics.

Flutter 3.35 landed 1,108 commits from 168 contributors, 39 of them first-time.

Practical takeaways

1. Update your launch configs. Remove --web-experimental-hot-reload — it’s dead weight now.
2. Treat --no-web-experimental-hot-reload as a diagnostic, not a setting. If you need it, file the bug.
3. Pair it with Wasm dry-run warnings. Developing on web in 2026 means simultaneously validating your JS build and your future Wasm build — both happen automatically now.
4. Re-test your workflows after upgrades. The web toolchain is moving quickly; a flag that was required last quarter may be a no-op this quarter.

Hot reload on web closes a long-standing gap between Flutter’s mobile and web developer experience. If you shelved Flutter Web because iteration felt slow compared to your JS framework, it’s worth a second look.