Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

211–220 of 748 posts

Re: We're forking Flutter

#211

Post by dotancohen »

epcoa wrote: post #204
1propionyl wrote: post #134

Earlier quoted context omitted.

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.

What's a native UI? The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)? And then Android? Ironic then that Google is the one behind Flutter. The concept of native outside of MacO…

I would consider both GTK and Qt native on Linux.

Re: We're forking Flutter

#212

Post by p1necone »

nostrademons wrote: post #137
maxrmk wrote: 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…

Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.

Re: We're forking Flutter

#213

Post by bhaney »

mg74 wrote: post #114
zerr wrote: post #90

Earlier quoted context omitted.

Modified Erlang. Genuine one didn't scale.

How so? Is there anything on what changes they made to Erlang/BEAM?

Process groups, some solid performance tweaks to ETS and Mnesia, etc. It all got upstreamed or became redundant eventually. Rick Reed gave a couple talks about it around a decade ago if you can track down recordings.

Re: We're forking Flutter

#214

Post by [deleted] »

odo1242 wrote: post #117
skybrian wrote: post #82

Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do. Shepherding these patches is no fun when you have you…

What is google3?

[deleted]

Re: We're forking Flutter

#215

Post by deergomoo »

divan wrote: 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…

> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell

You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb.

A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.

Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.

[0] https://flutter.dev/showcase

Re: We're forking Flutter

#216

Post by mardifoufs »

corytheboyd wrote: post #203

I like Flutter, and Dart for that matter, but I lost inspiration to keep going because it felt like I was learning something deeply that will be dead in a few years. Why not just learn Swift instead? Or if it must be cross-platform, Qt? Is this the right stance to take? I just want to pick a desktop app development stack that has some staying power, and isn’t riddled with quirks.

I guess flutter web is the "hook" because it promises a "true" cross platform stack, even though imo it is still very lacking. On the other hand, QT on mobile (iOS, android) is also a bit weird, and comes with lots of restrictions and gotchas. And it basically does not have any support for web apps (except for some super recent, very experimental wasm platform support, that would probably be even worse than the "app on canvas" experience that flutter web offers)

Re: We're forking Flutter

#217

Post by atentaten »

normie3000 wrote: post #19
justmarc wrote: post #8

Flutter is truly a piece of great tech with remarkable quality and value. I hope the right path will be found. I think companies using it for commercial purposes (like what we're doing) should contribute something to the effort to help make sure Flutter not only survives, but flourishes. Bug bounties, supporting individual developers, supporting efforts and initiatives, professional services, or any other way that he…

> Flutter is truly a piece of great tech with remarkable quality and value. How does it compare to React Native from user and developer experience perspectives? Are there other competitors?

I've been working with Flutter for a little over 2 years nonstop. Before I started this project, knowing enough react, I experimented with react native, Expo, also quasar, capacitor, nativescript, and other cross-platform mobile solutions. Flutter/Dart was just nicer to deal with than everything else. I needed to work with C code too, and Flutter made it straightforward with FFI.

The developer experience was great and the Flutter team was very responsive with questions I asked.

Re: We're forking Flutter

#218

Post by DaiPlusPlus »

maxrmk wrote: post #179
com2kid wrote: post #154

Earlier quoted context omitted.

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

Totally– This was in the early days of open source .net, when it was still called .net core. We had just moved onto GitHub and I don’t think microsoft had quite figured out how to manage that organizationally. There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHu…

> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.

That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.

———-

Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.

…now if only StackOverflow had that.

Re: We're forking Flutter

#220

Post by ClassyJacket »

kernal wrote: post #184
divan wrote: 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 the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell I agree with you that Flutter has been a boon for cross platform development, but to say it's impossible to tell you're using a Flutter app is a bit of an exaggeration. I have no problem identifying Flutter apps. Not that I care as they…

How do you know this isn't the toupee fallacy?

You spotted a few correctly so you assume you always spot correctly - but there might be more you miss.

https://rationalwiki.org/wiki/Toupee_fallacyhttps://rational...

Post reply on HN