What surprised me, what frustrated me, and what I'd do differently starting a Flutter project today.
I came to Flutter after years of building with React. I expected it to feel like React Native — same mental model, different rendering target. That assumption was wrong in ways that were both good and bad.
The widget tree is not the DOM
The first thing that trips web developers up is that Flutter's widget tree looks like JSX but behaves very differently. In React, components manage their own state and re-render when it changes. In Flutter, the widget tree is rebuilt more aggressively, and the distinction between stateless and stateful widgets is explicit and enforced.
Once you internalize that widgets are cheap and rebuilds are expected, the model makes sense. Before that, you spend a lot of time fighting it.
State management is a genuine decision
With React you have useState, useReducer, Context, and a small number of patterns that most teams converge on. With Flutter, the state management ecosystem is fragmented: Provider, Riverpod, Bloc, GetX, MobX.
I've used Riverpod on two projects now and it's become my default. The combination of code generation and compile-time safety catches a class of bugs that would only appear at runtime in most other approaches.
What I didn't expect to like
Hot reload. I knew it was fast, but the actual experience of changing a widget and watching the device update in under a second is better than I expected. It changes how you work — you try more things, iterate faster, correct course more often.
The layout system is also surprisingly good once you understand it. Flex, Row, Column, Stack — it maps cleanly to flexbox concepts, but with less footgun surface area.
What still frustrates me
Packages. The pub.dev ecosystem has grown significantly but still has gaps. Some packages are maintained by single contributors and haven't been updated in a year. Web platform support is improving but is still second-class for many packages.
And the framework update cadence is fast. Migrating between major Flutter versions is rarely painless.
Would I use it again?
Yes, for mobile-first projects where you need a single codebase for iOS and Android. Not for web — the web output quality still isn't where it needs to be for production use. Not for projects where the team is primarily web developers who'll spend their first month learning the framework instead of building.
For the right project, it's excellent. Knowing what the right project is saves you a lot of frustration.