Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

481–490 of 748 posts

Re: We're forking Flutter

#481
post #348

> How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong. > 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. This is a we…

Python's standard library rarely changes except deprecating features or new additions.

Underneath - POSIX + handful of Windows APIs for porting it to Windows. Cross platform aspect is mostly for the compilers to produce the binaries.

Flutter is not Python, PHP or Whatsapp. It has to emulate UI of six platforms (Web, Mac, Windows, Linux, Android, iOS) with easily 50+ widgets.

Flutter unfortunately is not comparable to a language interpreter. The surface area is altogether different.

Re: We're forking Flutter

#482

Earlier quoted context omitted.

I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…

> I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. There are DOZENS of us!!! I try my absolute best to find apps that use the native Apple language, both design and code. I can't stand these framework apps. I will Pepsi challenge this with anyone who asks…

> I will Pepsi challenge this with anyone who asks, I can smell a framework app.

The platforms ship with things like keyboard shortcuts for navigation and text entry, minimal accessibility features like screen reading of text and navigation, common idioms like drag and drop and the clipboard - none of which are typically handled by cross-platform widget frameworks by default.

Only gigantic projects like Chrome and VS Code will take on the effort of (partially) reimplementing these in their codebases to match platform behavior.

Re: We're forking Flutter

#483

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.

I think there should be a distinction here. E.g. if you work on a browser, possibly implementing parts of image loading, or javascript parser, etc.

Are you consider a dogfooder if you use the browser? or do you need to lots of write Javascript yourself, etc. to be considered "a user of your product"?

Typically, these are two different sets of people.

So, I don't buy the "always, always" part

Re: We're forking Flutter

#484
post #258

Earlier quoted context omitted.

The trouble with this is most users only use one platform and so don't care. They just see the app as badly implemented as it does not match other apps on the platform.

What kind of users/apps are these? I'm genuinely curious about this, actually. I have a couple of apps with 100K+ installs, and I talk to people who are actual users from time to time. I have never ever heard the claim that they don't like UI because it doesn't feel native. Like ever. But I can imagine that in some niches/demographics/app types it might be different. Can you share some evidence or explain how you bui…

A lot of people try an app and stop using it. Talking to active users seems you are missing the people who don't like it enough to stop using it.

Re: We're forking Flutter

#485
post #221
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. Flutter implemented its "native" looking UI widgets by literally having teams of designers eyeball the native designs and reimplementing, starting from drawPixel. This can't be done on a volunteer basis alone. Many open source attempts have tried this route and failed because they don't have the sheer…

> Flutter implemented its "native" looking UI widgets by literally having teams of designers eyeball the native designs and reimplementing, starting from drawPixel.

Those widgets are then stylized wrong on every subsequent platform release, such that your iOS 18 phone might seem like it is launching an iOS 7 app.

IMHO if your goal is to have a cross-platform codebase act like the underlying platform, React Native is a much better approach. Flutter exists for people who don't intend to take on the effort of targeting platforms with specialized behaviors.

Re: We're forking Flutter

#486
This is a kind of a strange argument:

>How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong.

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

It's like claiming that the inventor of penicillin, was responsible for billions of people who took pennicilin.

Re: We're forking Flutter

#487

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

Common misconception is that you open source something and contributions will flock in. Doesn't happen that way.

And even if happens - changes can't be merged without thorough and careful review. So who's do the reviews when supposedly there are too many contributors? Only someone who fully understands that particular subsystem.

Which means we're back to square one because as per post there are only three subject matter experts available for the new fork.

Re: We're forking Flutter

#488
post #348

> How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong. > 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. This is a we…

> This is a weird exercise. Python, for example, is a #1/#2 language in the world and there's only 50 active core devs, 90% of which don't even work on Python full time. Somehow we make that work.

But that leaves Python slow and single threaded.

Re: We're forking Flutter

#490

Earlier quoted context omitted.

> This could explain a lot. Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.

I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.

Django comes to my mind here. The people behind the framwork had real experience and needs in web publication.
Post reply on HN