Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

651–660 of 748 posts

Re: We're forking Flutter

#651
post #643

I think a big problem is that Flutter's approach is very labor intensive. It takes over responsibility for the UI, which is tough when you want to be cross-platform. You need to keep up with the native UI across all the platforms. (Or, of course, you don't, in which case there are gaps, bugs, inconsistency, jank, etc.) Beyond the UI, it needs to offer integration with platform services and conventions, which is anoth…

> You need to keep up with the native UI across all the platforms. (Or, of course, you don't, in which case there are gaps, bugs, inconsistency, jank, etc.)

And for the latter, the result is something that mostly does what web-based solutions do (with well-understood downsides), only with virtually no ecosystem in comparison.

I do think there are opportunities for cross-platform native development solutions like https://skip.tools/, which offer an alternative to React Native.

Re: We're forking Flutter

#652

Earlier quoted context omitted.

In those cases, those app developers aren't doing cross-platform development, but are just trying to dump their app in as many places as possible. In such a case, why not just make a PWA and call it a day? Don't need an app if you aren't going to go native, especially with most apps being either content readers or CRUD apps anyway. In most cases, I personally rarely want an app, and I'll use a website unless they hap…

Because most users have no idea what a pwa is or how to install it. They expect to be able to go to the app store and install an app.

That is exactly the reply I was hoping for. Because that brings us straight back to the native issue; users also expect the app to work in a way that is comfortable and known to them.

Re: We're forking Flutter

#653
post #644

Earlier quoted context omitted.

Depending on widgets external to the toolkit is a no-go for me. It unnecessarily bloats dependencies and there’s a high risk of the widget eventually being abandoned.

I totally get your sentiment and also try to instill the culture of "add dependency only if it's absolutely not possible to avoid it". For small widgets, I often just copy the code into my tree. And I absolutely hate when library authors break API for no reason (something that the Dart ecosystem inherited from the web one). But limiting yourself only to standard widgets seems to be extreme.

It’s not that I limit myself to standard widgets, it’s more that the toolkits I use have a full enough complement of standard widgets that any custom needs are easily met by tweaking one of those.

In UIKit for instance I typically build custom buttons by subclassing UIControl, which gives a nice “blank slate” control that has all the basics of interaction covered without the specifics of UIButton. It’s easy to build a custom button that’s as well-behaved as a standard UIButton that way.

Re: We're forking Flutter

#654
post #306

Flutter founder here. We use Flutter to build Mezzi (www.mezzi.com). In fact, we've worked with the OP (Matt) on our app. He's super knowledgeable about Flutter and it's inner workings. A great dev too. Flutter is awesome, but there are definitely bugs that lie unfixed for an uncomfortable period of time. This is not unique to Flutter ... with any open source project there's a lag between bug reports and bug fixes. T…

> Flutter founder here. Given that the literal founder of Flutter is in this thread using this introduction multiple times, it’s kinda hard to give you the benefit of the doubt that you honestly just meant “a founder using Flutter”.

I meant to say, "Founder using Flutter here".

Re: We're forking Flutter

#655
post #306

Earlier quoted context omitted.

> Flutter founder here. Given that the literal founder of Flutter is in this thread using this introduction multiple times, it’s kinda hard to give you the benefit of the doubt that you honestly just meant “a founder using Flutter”.

What was that phrase about not assuming malice when you could assume something else? Most likely GP saw the actual Flutter founder announcing themselves as "flutter founder" and assumed it was a common phrase for founders who use Flutter lol.

That is seriously what happened. I didn't realize the actual Flutter authors were here using that phrase. Because it sounds odd to say founder for author of a software package. I genuinely thought those were Founders using Flutter.

Anyway, my bad.

Re: We're forking Flutter

#656
post #306

Earlier quoted context omitted.

> Flutter founder here. Given that the literal founder of Flutter is in this thread using this introduction multiple times, it’s kinda hard to give you the benefit of the doubt that you honestly just meant “a founder using Flutter”.

I remember the name 'hersheyhersh' in some Flutter context. But the account has zero activity, so it's questionable that this is a Flutter founder.

I am not the Founder of Flutter. Sorry. I am a founder using Flutter. Just skimmed the comments and saw the phrase used multiple times and thought those were founders using Flutter, and thought to use the same term.

Re: We're forking Flutter

#657
post #306

Earlier quoted context omitted.

> Flutter founder here. Given that the literal founder of Flutter is in this thread using this introduction multiple times, it’s kinda hard to give you the benefit of the doubt that you honestly just meant “a founder using Flutter”.

I believe he means "a founder who uses Flutter". Poor wording, but I don't think it was intentional.

Thank you.

Re: We're forking Flutter

#658

Earlier quoted context omitted.

Very rarely do the people working full time on a framework/tool also use that framework/tool in a non-toy setting. They aren't working two full time jobs after all.

Always, always, dogfood what you produce. The number one way devs cease making products people care to use is by not using what they make.

Dogfooding doesn't mean you know how to build it. Take for example the graphics engineers on Unreal Engine. They almost certainly know how to fly around test zones or make stress scenarios, but they aren't going to be building large, detailed, open world maps like will be seen in the next Cyberpunk or whatever. And it's not reasonable to expect that of them, either.

Nor are the people doing UI work in Blender going to be able to make Big Bunny.

Nor are the people working on fusion360's parametric system going to build complex mechanical-fluid simulation scenarios.

Flutter is simpler than those, sure, but even in that world you have people that do nothing but fonts & text for their entire careers. They'll know how to do text stuff in flutter, but they'd be lost if you demanded they make a tiktok clone.

Re: We're forking Flutter

#660

> 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. If "only" 50 people working on a project used by one million people was unworkably low then every single successful project out there would be doomed.…

It absolutely reads this way, and this person is in for a rude awakening. I thought all the Flutter team was laid off from Google anyways, effectively making this project dead in the water. Looks like there is a someone left over that can't let it go and just move on from the past.
Post reply on HN