Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

151–160 of 748 posts

Re: We're forking Flutter

#151
post #141

Earlier quoted context omitted.

> Just build native UIs Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?

Yeah I do see why they don't want to do it and I see it as a critical failure of risk management. If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs. The risk analysis of building against supposed cross platform "solutions" just doesn't work…

Back in the real world however you have canonical for years now who have made flutter the default for all native linux desktop development.

I think your anecdotes are a bit out of date and irrelevant.

People much better informed than you looked at this problem in a lot more detail in real life situations and came to very different conclusions.

Re: We're forking Flutter

#152
post #29
post #6

> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix. they could pay contributor or issue bug bounty..

Based on the article's premise getting that merged is the problem, not fixing code.

right, making maintainers happy is part of that work.

Re: We're forking Flutter

#153
post #133

> That's 50 people serving the needs of 1,000,000. [...] 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. 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.

Curl is easily 1000x simpler than Flutter and has existed for many times longer. Not really comparable.

Re: We're forking Flutter

#154
post #30

> 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…

> 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 we'd usually reply that day.

It depends on an org's priorities and what gets put on someone's reviews.

During one of the years when I worked on Windows Mobile (before Windows Phone!) we had an objective handed down from on high that we were to spend so many hours a week on customer support forums helping people out.

Well, for that year, customers all around the web got great support right from engineers! I got to paste lots of positive feedback from end users in to my yearly review, and I felt great about it!

If Google cared about supporting Flutter as an Open Source project, they'd make the health of the open source project one of the measurements going into employee reviews at the end of the year.

Re: We're forking Flutter

#155

Earlier quoted context omitted.

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.

> 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?

no, if I'm using your platform, it's because I really don't want to deal with the stinking pile of abstraction below that. so on the contrary, I would see it as a negative if the abstraction was that leaky.

Re: We're forking Flutter

#156

Earlier quoted context omitted.

What a bizarre statement. cURL is basically maintained by a single person, and nearly the whole world uses it.

> cURL is basically maintained by a single person Suppose Flutter may be an order or two magnitude more complex than cURL.

glib then?

Re: We're forking Flutter

#157
post #151

Earlier quoted context omitted.

Yeah I do see why they don't want to do it and I see it as a critical failure of risk management. If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs. The risk analysis of building against supposed cross platform "solutions" just doesn't work…

Back in the real world however you have canonical for years now who have made flutter the default for all native linux desktop development. I think your anecdotes are a bit out of date and irrelevant. People much better informed than you looked at this problem in a lot more detail in real life situations and came to very different conclusions.

> you have canonical for years now who have made flutter the default for all native linux desktop development

And yet, I can't think of a single app I depend on for anything on Linux that relies on it.

How'd Snap go for Canonical?

Re: We're forking Flutter

#158
post #30

> 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…

Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet. 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 th…

I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs.

It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.

Re: We're forking Flutter

#159

Earlier quoted context omitted.

If you think its not popular until that increases past one of: JS, Python, Java, C#, PHP, C/C++, Ruby, Go, or SQL...I don't really know what to say. :)

Flutter in Kotlin instead of Dart would have killed ! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).

Yes, I agree, trying to use Kotlin instead of Dart would have killed Flutter.

I've been hearing about Kotlin multiplatform just as long as flutter, and writing Kotlin since 2019.

Kotlin is a horrible daily driver.

I worked on Android for Google at 7 years, and maybe it'd have a better chance if it didn't win internally. As it stands, there's too many organizational boundaries created, and each organization holds itself accountable only within itself, so it's sort of the worst of all worlds, impedance mismatches everywhere, and nobodys fault they exist

I'm always stunned to read wish casting about Kotlin because there's ~0 path to even basic things that change productivity dramatically, like hot reload.

Re: We're forking Flutter

#160
post #120

> 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…

Flutter is really not some big revelation and it's always shocking to me how it's evangelists act like it's the game changer no one else has noticed. 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.

As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.
Post reply on HN