@mihalycsaba that’s a good question! I was a part of the Flutter team until about a month ago (and shared more details about this in another thread). But from my time there, I remember seeing folks like Victor, Valentin, and Flop being welcomed into the team—not to mention the folks from Canonical who joined to help out with multi-window support—so overall it definitely looks like they’re geared toward growth.
@Mdh you make a really good point about the expectation that a UI configuration present in the Material 3 spec should be part of Flutter’s Material library. And I can absolutely relate to feelings of frustration over decisions made by the people in charge of the Flutter team.
But “gaslighting” is a type of manipulation where the intent is for the victim to question their sense of reality. As far as discontinuing packages like flutter_adaptive_scaffold, I agree with the decision and feel strongly that no gaslighting has taken place.
- The reasoning behind this decision was communicated at the beginning of the announcement: it’s “in order to focus the Flutter team’s resources on core functionality”.
- With regards to the native Android ecosystem, the canonical screen layouts can be found in the
user-interface-samplesrepo. This is not a core framework, but rather is a collection of code samples that a developer can download and tweak as desired. (I also discovered that this repo is out-of-date according to the README.) - I disagree that the change lacks any sense of warning. An announcement was made on February 9 and will go into effect on April 30; IMO that’s a reasonable amount of advance notice.
The explicit goal of the GitHub issues is to promote “discussion and coordination of alternatives, forks and future ownership”, and based on what I’ve read this seems to be progressing smoothly.
During my experience reviewing issues and PRs within the Material library, I noticed that when a single widget tries to do a bunch of things, it’s an invitation for an un-ending queue of people requesting tweaks for their specific use cases.
Whereas native Android has code samples available on GitHub, Flutter has something better: interactive DartPad samples that can be directly embedded into a website.
I love the way docs.flutter.dev and api.flutter.dev take advantage of this capability. When a UI configuration is shared by way of code samples rather than custom widgets, developers still achieve the functionality they want, and they can tweak the design directly without needing to wait for changes to the framework. (Not to mention how keeping the focus on composability promotes ideal performance by mitigating API bloat.)
For adaptive design to be “handled for us” makes things more convenient, but that’s not why I chose Flutter: I fell in love with Flutter’s performance and Dart’s amazing language features, because my ability to create beautiful cross-platform experiences is an amazing feeling.