Details are here: ☂️Packages being discontinued · Issue #162960 · flutter/flutter · GitHub
Most of them I think are reasonable enough personally. Curious to see what others think?
3 Likes
I use flutter_markdown in some cases, and for me that seems the only one.
1 Like
Found it a thoughtful decision. Time for the community to step up on those packages and let the Flutter/Dart team focus on top features.
1 Like
Honestly, I kind of disagree that it was a thoughtful discussion. Take this issue for example where the responses honestly felt like straight up gaslighting by claiming simultaneously:
- these threads were made so that discussion could happen but also all of the comments are marked as off topic and everyone was scolded for trying to talk about it by pointing to a set of rules that do not actually back up why the conversation is shut down.
- claiming that many people were consulted before this decision was made but also we can’t point to any actual evidence of that happening.
- Claiming that things like popularity were used as some key part of the decision making process but unable to explain how this package with almost 10,000 downloads a week was chopped while some ads junk with less than 5 downloads a week was kept.
Just as a note to any Flutter dev rels like @kevmoo @CraigLabenz and others out there: the main reason I and many others like me choose a framework like Flutter to begin with is precisely because the core value proposition is cross platform, uniform design systems where apps work on any screen of any device and any size and when you do something silly like this where you just straight up delete the only implementation of the “screens of any size” part of it without any public notice it makes people very nervous. The gaslighting that went with it in this thread just made it worse.
3 Likes
flutter_adaptive_scaffold should be maintained. What is the point of having a cross platform framework when you don’t have any easily way to build an adaptive app?
The package helped us push app to different screen sizes easily.
5 Likes
The package already works. You can easily build an adaptive app with it.
They’re not saying “it kinda works can someone finish this off for us please?”.
4 Likes
FYI – I’m watching this thread and am happy to relay messages to the folks in charge of these packages on the team. I’m hoping that this thread can be the central place that all feedback and questions funnel through. (Unless you’re interested in contributing or taking over one of the packages, then you should use Github).
It’s of course possible that there are use-cases for these packages that we failed to consider, and we’re happy to continually re-evaluate!
If you have strong feelings about any specific packages listed being discontinued, please comment with your use-case, how critical it is, what you’ll do with this new information, etc. Any info is helpful!
2 Likes
“Not that easy, once it is a piece of Google code it becomes their intellectual property…” and all the code you write when you work for them is theirs.
It is not just a matter of taking it over you will need to negotiate with Google for the IP
That’s simply not the case. The announcement is explicitly looking for folks to fork the package. Forks of Flutter and related packages happen all the time, and no one has ever had to “negotiate” for those forks. You can look at the LICENSE file for any package to see the legal requirements for forking it.
5 Likes
Last time I used that package, I had to do lot of work arounds to match the material 3 spec!
1 Like
Wow! Apologies I assumed it was already matching Material 3 spec
Did you submit your changes as a PR? Sounds like the changes you made could be very useful to a lot of people
3 Likes
Hi Eric,
I just wanted to make sure I had the chance to follow up on this offer to at least take into consideration some of the community feedback on this issue as like I hinted at before and like others mentioned in the Github issue, I feel that has been sorely lacking up until this point unfortunately.
The core of my gripe with this particular situation is focused entirely around the adaptive scaffold package and specifically as to how this decision is completely out of step with expectations.
At no point was the community ever consulted about this, it was simply told to them as a matter of fact and then implied that there was no opportunity to second guess it.
When pressed as to what possible criteria was used to determine which packages were to be no longer maintained only an incredibly vague answer was given that seemed to indicate popularity was a meaningful factor but that just isn’t at all borne out by the actual numbers when we look at other packages maintained by the team on pub.dev so that part absolutely felt like gaslighting.
The other MAJOR issue I have with this however, is really to do with the expectation I have when it comes to what this package represents and the commitments that comes with. When I look at other ecosystems like Android for example it’s literally a core part of their implementation of Material Design that lives inside of their core repository and when I look at Material Design’s guidelines, it too is a core part of their design system so to be honest it feels REALLY strange to have this as:
- Some external package independent of the rest of the Material Design implemtation inside of the Flutter framework.
- Is also not not supported and there is nothing at all coming to replace it, we are told to build it ourselves as the community, again, not as a part of any conversation, not part of any objective metrics that anyone can point to, not with any sense of warning…
I just am completely unable to reconcile this being the very first thing that developers are shown on the Flutter homepage
…with the fact that the only public implementation that allows you to do that out of the box, no longer exists.
That kind of whiplash is exactly the kind of thing that people regularly point to when they feel like Google as an organization can be an extremely unreliable partner.
This whole experience just left an incredibly bitter taste in my mouth and the way it was handled in the Github issue really only compounded that feeling. It was unpredictable, it was unprofessional and it was completely at odds with so much of the rest of the messaging that developers are told over and over again and it was ultimately the kind of thing that just destroys trust and I can not for the life of me understand to what end, this was just such an own goal for no good reason.
Just to make it explicitly clear, I along with millions of other developers choose Flutter for the explicit reason that this kind of stuff is handled for us. That’s the entire value proposition, just lit on fire.
I genuinely appreciate you reaching out to at least collect the feedback in the meantime.
5 Likes
Are they still downsizing the team?
@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.
2 Likes
Hi @nate-thegrate thanks for the thoughtful response. I wanted to get back to you on a few of the points you made just to walk you through some of my thinking and to clear up a few things that I think were maybe not communicated clearly.
I thought maybe it’s worth starting with the usage of the term gaslighting because it was absolutely used in a moment of frustration and I think it’s fair to question if that was appropriate or not.
I would preface it though by saying that:
- I said it felt like gaslighting (an opinion based on my personal experience not necessarily an accusation of an actively malicious action which for the record I don’t think is what happened).
- It was in response to a very specific thing where in the thread it was asked if there was any kind of actual criteria that anyone could point to and popularity was listed as one of the major factors and then it was pointed out that this particular package had 8,000 downloads a week while another had 3 downloads a week but that wasn’t considered. So yeah, in that case it did feel a bit gaslight-y to be totally honest with you.
Looking back over the thread now there are actually a bunch of other factors that lead me to that same conclusion but given the fact I don’t think anything actively malicious was taking place I don’t know that litigating them line by line is appropriate. I simply felt the way I felt, I continue to feel that way but I don’t mean to claim that as anything else other than a personal feeling if that makes sense.
To get back onto the core topic though, you were right that is given the wrong link to the Android repo but I think that’s maybe the wrong level of detail here as well. I thought maybe it would be more appropriate to just capture some of my main points and assumptions so we can see if any of them are maybe misguided or particularly uncharitable for example:
- Canonical layouts are a core part of the Material Design specifications and other comparable platforms provide implementations of them.
- One of Flutters key value propositions is the idea of apps that look great on any screen.
- Materials canonical layouts are literally the spec solution to that idea of “apps that work for any screen size”.
- I think it’s very weird as I mentioned to have that carved out as anything other than a core part of Flutter’s Material implementation let alone one that’s no longer supported given Flutter’s own value propositions.
- Many tens of thousands of developers all across the road had understood this to be a part of the core specification as evidenced by download numbers and the fact it wasn’t in labs and they then went ahead to rely on it in really core parts of their applications.
- The first time the public heard about this was after the decision was already made and it was without any kind of possible recourse. In fact feedback was actively discouraged on GitHub and it was only later that we were told to discuss it amongst ourselves on a forum like this.
- The lack of clear communication, the lack of transparency and the mismanagement of expectations leads people to wonder what else could possibly be axed next without consultation and that is bad for everyone and sets a horrible precedent.
I think that mostly covers my thinking and hopefully clears things up a bit. Like I said I was rather annoyed at the time and recognise somethings might be taken the wrong way. I don’t mean to personalise any of the criticism, everyone is just trying to do their job as best they can but I do think this was handled poorly for the reasons stated.
1 Like
@Mdh thanks very much for responding, and especially for acknowledging the subjectivity involved in your initial reaction.
In my mind, the Flutter team has a right to choose how to allocate their resources, and this includes decisions to drop support for ABC in order to focus on XYZ. But I also agree with your concern that announcements like these give reason to wonder what might be axed in the future without prior consultation.
One thing that’s helped my perspective is to take provider as an example: the package is well-received (averaging 800,000+ weekly downloads) and notably is not maintained by the Flutter team.
Or in other words: Flutter has InheritedWidget baked into the framework but also allows you to import third-party packages that make inherited widgets easier to use.
Likewise, Flutter comes with many RenderObjectWidget subtypes (such as Row, Column, and DecoratedBox) but also allows you to import third-party packages to make adaptive designs easier to implement.
With regards to the Material 3 spec (which currently links to a package in the process of being discontinued): one solution could be to update it to point to the Adaptive design | Flutter page instead, and possibly update that page with interactive samples and/or links to community packages that have been well-received. @ericwindmill I suppose that’s the main piece of feedback I wanted to share 
1 Like
Just as some quick points regarding what you said.
I’m not for a moment suggesting that good things can’t come from the community or anything like that, I’m simply suggesting that you have to squint REALLY hard to come to a conclusion that something this fundamental and closely linked to the main value proposition of Flutter is somehow not their responsibility though. I just can not for the life of me, even with my most generous take get to that conclusion unfortunately.
And then to your point about it’s their right to pick and choose what they work on. Again, I wouldn’t disagree with that statement as a matter of principle or just a matter of reality that nobody is going to force them to do anything that they don’t want to do.
But beyond the concept of their rights is also the concept of their responsibilities and our expectations and a bunch of other relevant factors here at play.
I think we as end users of the product do have a reasonable expectation that core parts of the products value proposition will not disappear overnight without consultation or recourse for example.
I do think they have a responsibility to communicate and engage with the community on things like this and take feedback into account ahead of time for example.
When they don’t want to do that or want to set different expectations they can use established patterns like the the labs publishing setup but that isn’t what happened here at all.
So, yes on the topic of their rights, but also it’s a single piece of the puzzle rather than the entire story I think.
2 Likes
Hey @ericwindmill i just wanted to check in and see if you had actually had a chance to pass on any of this feedback at all yet?
One of the main gripes I had initially here was really around the fact that this experience kind of sent a loud signal that there was zero the community could actually do to influence anything in practice, all decisions were made without consultation and that there wasn’t any real interest in actually listening to any feedback in practice as evidenced by all the comments being hidden on the GitHub thread and then being told to essentially talk amongst ourselves here.
When you said that you were happy to advocate or at least pass on the feedback to the right people I was super happy and tried to put some actual effort in trying to articulate that. But this thread just died for a week since then and I feel kind of stupid for having put in that time to do so now and it’s just reinforced a lot of the negative feelings I’ve had about the entire affair.
In a more generous take I know everyone is really busy in real life and it’s easy to have things fall of the radar for any number of reasons so I just wanted to try one last time if possible. Thank you for your efforts in the meantime.
1 Like
In my opinion, I believe this is the right decision because the Flutter team should focus on the framework and make it more stable instead of spending time implementing and refactoring packages. Additionally, I think they should integrate something like the GoRouter package directly into the framework.
1 Like
I think they should integrate something like the GoRouter
Please, don’t.
IMO, both Cupertino and Material should be OUT of the framework (the framework should be as core as possible)
1 Like