Flutter 2 and the Web: A Real Assessment

By October, Flutter had become the obvious choice for new mobile projects at a lot of companies. The question people were asking wasn't "should we use Flutter?" but "can we use Flutter for web and desktop too?"

The promise was appealing: write once, run everywhere. Android. iOS. Web. Desktop. One codebase, one team, massive code reuse. Flutter 2 was supposed to make this real.

I spent October reviewing actual Flutter web projects to understand whether the promise matched the reality.

The Android and iOS Story (Already Works)

Before diving into web, I want to be clear: Flutter for mobile is genuinely solid. I've shipped multiple apps with it. The developer experience is great. The performance is good enough for most use cases. The hot reload and build times are genuinely better than native development.

For a new mobile-only project, I'd choose Flutter. The only caveat: if you need very specific platform behaviors, you'll fight the abstraction layer. But for most apps, Flutter handles it fine.

The Android and iOS ecosystem around Flutter was mature by October 2020. Good libraries. Answers on Stack Overflow. Patterns that work.

The Flutter Web Question

Flutter web is different. It's not mature. I don't think it's production-ready for most use cases, and I'll explain why.

The output problem: Flutter web compiles to JavaScript. Not particularly optimized JavaScript. The bundle size is often 2-3 MB of compiled Dart running on top of a Dart runtime that adds another 1+ MB. A basic "hello world" Flutter web app is 3 MB of JavaScript. A React equivalent is 30 KB.

This matters on the web in ways it doesn't matter on mobile. A 3 MB download on a 4G phone might take 5 seconds. A 3 MB download on a slow internet connection takes much longer. Users bounce.

The Flutter team would say "the framework overhead gets better as your app grows." That's technically true. But the baseline is still high.

The performance problem: Even after it downloads, the JavaScript runtime has to initialize. The page isn't interactive for several seconds on a slow device. Compare that to a web page that renders HTML immediately and becomes interactive progressively.

I tested Flutter web on a Pixel 3a with 4G throttling. "Hello world" took 4 seconds to become interactive. A React app took 0.5 seconds. For a web app, that's an eternity.

The interaction model problem: Flutter is built for touch. The interactions are optimized for fingers, not mice. The scrolling behavior is slightly different. The hover states are weird. None of this is bad, but it feels foreign on web.

You can build a Flutter web app that works fine, but it'll feel like an app that was built for mobile and shipped on web. Which it is.

The accessibility problem: Flutter's web accessibility story is still immature. Screen readers have trouble. Keyboard navigation requires extra work. The tools that make web apps usable for people with disabilities aren't fully integrated yet.

If you need to support blind users or people using only keyboards, you're fighting against Flutter web's architecture.

The Desktop Question

Flutter desktop (Windows, macOS, Linux) is even less mature than web. The story is similar: it works, but.

The bundle sizes are large. The performance isn't great. The UI doesn't feel native to the platform. You end up building something that works the same across Windows, macOS, and Linux, which means it doesn't feel at home on any of them.

For internal tools, this is fine. For user-facing applications, the lack of platform feel matters.

The Real Cross-Platform Story

Here's what I think is actually happening: Flutter is great for mobile. Flutter web and desktop are functional but not competitive with platform-specific approaches.

If you're choosing between:

• One team building Flutter for everything
• Three teams building native iOS, Android, and web

...the Flutter team will be more productive and ship faster. You'll make tradeoffs on the web and desktop, but you'll be done sooner.

If you're choosing between:

• One team building Flutter for mobile with native web (React)
• Separate teams for mobile and web

...you'll get a better product on both platforms but at higher cost.

The question becomes: what's your constraint? If it's engineering resources and speed, Flutter for all platforms is a reasonable tradeoff. If it's product quality and each platform mattering equally, you probably need platform-specific approaches.

What Changed in October

The key thing that changed for me was seeing actual Flutter web apps in production. They worked. They were functional. But they felt slow compared to web apps built with React or Vue.

I reviewed a Flutter web dashboard that was genuinely impressive engineering. The developer had written once in Flutter and deployed to iOS, Android, and web. The functionality was identical everywhere.

But on web, it was noticeably slower. The bundle was larger. The time-to-interactive was longer. It felt like an app running on the web instead of a web application.

A React developer building the same thing would've made different tradeoffs: larger bundle to improve JavaScript parsing time, smaller initial render to get something on screen faster, platform-specific styling for each device type.

Flutter's cross-platform abstraction obscured those platform-specific optimizations.

Where I Land

For new projects in October 2020:

Mobile-only: Flutter is the obvious choice. Better DX than React Native or native. Good enough performance. Mature ecosystem.

Mobile + Web: I'd probably build mobile in Flutter and web in React. The extra work of maintaining two codebases is worth the better web experience. Flutter web exists but feels like punishment.

Mobile + Web + Desktop: This is the one where Flutter shines. One team building everything. The web and desktop experiences won't be perfect, but they'll exist and work, which is better than having to hire more teams.

Internal tools: Flutter for everything works fine. The visual fidelity matters less for CRUD applications.

Public web app: I'd probably avoid Flutter web. The performance and accessibility tradeoffs aren't worth the code reuse.

The Trajectory Question

I'm genuinely curious where Flutter web goes. The team is working on it. The bundle size is getting smaller. The performance is improving. By 2021 or 2022, it might be genuinely competitive.

But in October 2020, it's not there yet. Flutter web works. I wouldn't ship user-facing web applications with it today.

The bigger question is whether Flutter's cross-platform promise is actually the future or whether we'll accept that different platforms require different approaches.

By end of year, I expect Flutter will have made progress. But I don't expect to suddenly recommend it for web over React. The tradeoffs will just get less egregious.