131–140 of 748 posts
To still use flutter in the name when your project is called flock seems beyond misleading.
Also, there is an existing messaging and collaboration tool called Flock: https://www.flock.com/
They estimate there are one million Flutter developers/users. Have I been sleeping under a rock?
Some relevant data:
- Over 165K GH stars
- Over 140K subredditers
- Over 500K YouTube subscribers
The 1M estimate is at least ballpark accurate.
Ever heard of e.g. curl? Because a billion users use your software does not mean that you have to talk to a billion users.
> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…
It's just not that good?
Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea.
> flutterfoundation.dev It's not Flutter by own admission, it's very likely not backed by a foundation, and I highly doubt that Google consented to its "Flutter" trademark used for such a foundation.
They estimate there are one million Flutter developers/users. Have I been sleeping under a rock?
> That's 50 people serving the needs of 1,000,000. Doing a little bit of division, that means that every single member of the Flutter team is responsible for the needs of 20,000 Flutter developers! That ratio is clearly unworkable for any semblance of customer support. Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github…
Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Earlier quoted context omitted.
Thank you for creating my favorite app framework. That said, I literally only use Flutter as a hobbyist. I made a basic web game for a friend, and a small web app that helps me manage my music lyric videos. I ultimately picked Flutter because I find it easier than actually building websites. Dart is amazing. But I'm not deploying to millions of users. At most 10 people have seen my Flutter apps. It's VERY good for cr…
on behalf of one of the Flutter founders, thank you for the thank yous. I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for. Quick Google shows Dart 10th, right below SQL, right above Kotlin. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
Earlier quoted context omitted.
WhatsApp had less than 50 engineers (or was it employees total?) when Facebook bought them out, and they had millions of users.
WhatsApp has a very narrow use case and feature set to support. Flutter is a multi-platform framework for developing apps like WhatsApp. It seems like a apples and oranges here.
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
Earlier quoted context omitted.
We got around 3m with seven guys, so yeah, and we don't even have on-call rotation / schedule, even though emergencies do happen from time to time. They think 1:1000 ratio is too big as well? That's crazy.
Are you comparing a developer platform to consumer software there? Dev platforms have radically different support costs to regular SaaS or mobile apps. Developers are really support intense.
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?