Could you expand on this a bit? My impression was that Flutter and React had relatively similar approaches to components, but I haven't had much experience with Flutter yet, so I'm interested to hear your experiences!
Could you expand on this a bit? My impression was that Flutter and React had relatively similar approaches to components, but I haven't had much experience with Flutter yet, so I'm interested to hear your experiences!
It’s genuinely hard for me to overstate the general quality of life improvements both from the developer experience and the overall quality of the apps I can produce in any given time frame.
A big part of the reason for that is Dart is itself hands down the nicest language I’ve ever worked with. The team behind it got real serious when it comes to tooling and language design and everytime I have to go back to TypeScript I feel like I’m trying to run with a 50kg backpack on.
But it's really the Flutter/Dart API and widgets that make it much easier to work with, if I need to load some data asynchronously I use a `FutureBuilder`, if I need a stream of events I can use `StreamBuilder` etc. Compared to Reacts state, hooks, memo, effects etc. you end up with code that is far easier to reason about what is rendering when and why.
Oh and the real killer feature is Flutters hot reload experience, it's easily the best DX I've seen for GUI work.
As another comment mentioned it really is like night and day. I recommend giving it a try.
But I can imagine that the API can be easier. I think React handles state fairly well, but as soon as that state needs to interact with things outside the React world (http requests, continuously updating data, etc) then the current abstractions don't quite feel right.
Yes, that's basically correct:
>Calling setState notifies the framework that the internal state of this object has changed in a way that might impact the user interface in this subtree, which causes the framework to schedule a build for this State object.[0]
The `build` method rebuilds the entire widget tree. So "the whole app" does not necessarily get re-rendered, only whatever is in the same widget as the changed state or below it, although potentially that can be the whole screen. Flutter also uses an algorithm to detect unchanged widgets and reuse them,[1] but conceptually the whole thing is re-rendered on state change.
[0] https://api.flutter.dev/flutter/widgets/State/setState.html
[1] https://docs.flutter.dev/resources/inside-flutter#linear-rec...
Flutter = a UI framework for mobile/desktop/web (Flutter + Dart)
On top of the purpose built nature, nearly everything is a Widget, even layout/styling making it pretty easy to grok very quickly.
Dart has its own build tools and package system that work well. You can still pull in dart libraries as you need them. Dart is also a much better language than JS. I can't tell you how many days I've lost to react/JS build tooling issues. A single problem can easily eat an entire day. With flutter/dart I haven't had a single issue like that.
the job market for dart flutter is a drop while react is the lake.
react with electron, react native, react itself together are still the only ones production ready cross platform GUI with widest adoption
The first and the third paragraphs really haven’t been true for some time now.
Flutter is absolutely production ready as a cross platform GUI.
On the other hand I think flutter lost a lot of benefits comparing to 5 years ago - now we have stable better swift and swiftui and better kotlin with jetpack compose - those support also apple watch, macos, tvos, visions os, Google wear, Google TV and with current jetbrains compose desktops like windows is already stable.
React native and web ecosystem also improved a lot in the last year.
If I am remembering correctly the headcount on the Futter team literally changed by a single person.
Here are some actual real life numbers you can use if you want to gauge the health of the two projects:
1. https://github.com/facebook/react-native/pulse
2. https://github.com/flutter/flutter/pulse
Specifically Flutter’s 108 merged pull requests to React Native’s 1 and Flutter’s 330 closed issues to React Native’s 18.
Also note that this doesn’t even include their rendering engine which had another 90+ closed pull requests https://github.com/flutter/engine/pulse
The truth of the matter is that Flutter is actually is far better shape both from a technical and open source perspective.
The health of the two projects genuinely isn’t close at all. Comparing what they are actually both shipping in terms of features in the last year is two very very different stories.
Flutter monthly pulse: https://github.com/flutter/flutter/pulse/monthly "Excluding merges, 83 authors have pushed 451 commits to master and 461 commits to all branches" but:
1st engine-flutter-autoroll (bot with revisions autoroll): 185 commits
2nd zanderso (google employee): 25 commits
3rd ValentilVignal (contributor): 14 commits
in top 15 contributors for flutter you have also other bots such as: fluttergithubbot, auto-submit[bot], flutter-pub-roller-bot, dependabot[bot]
React Native monthly pulse: https://github.com/facebook/react-native/pulse/monthly "Excluding merges, 84 authors have pushed 437 commits to main and 575 commits to all branches"
1st cipolleschi (meta employee): 92 commits
2nd cortinico (meta employee): 83 commits
3rd NickGerleman (contributor): 45 commits
no bots in top 15 contributors
Also keep in mind React Native is based on React repo project. On top of that you have a lot of work by community in:
- expo https://github.com/expo/expo
- react native reanimated https://github.com/software-mansion/react-native-reanimated
- react navigation https://github.com/react-navigation/react-navigation
- react native skia https://github.com/Shopify/react-native-skia
All of those packages are highly maintained and are pretty used in all RN projects and considered standard.