Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

511–520 of 748 posts

Re: We're forking Flutter

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

I know this isn't a Apples-to-Apples comparison but antirez was the sole maintainer (after creating it) of Redis for more than decade[1]

[1] https://redis.io/blog/thank-you-salvatore-sanfilippo/

Re: We're forking Flutter

#512
post #477

Earlier quoted context omitted.

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

> but I know that's down to the developer so I won't hold that against Flutter. That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.

> the underlying platform UX and draws to a canvas

Frame buffer? Canvas is the javascript term.

Re: We're forking Flutter

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

> having teams of designers eyeball the native designs

No wonder it's not accurate.

Re: We're forking Flutter

#514
A lot of people here are comparing Flutter with programming languages like Python, PHP, etc. It shows how under appreciated UI development is and the amount of complexity UI developers need to handle. Also UI framework developers are always at the mercy of someone else when it comes to their destiny, unlike programming language creators which "almost" control it fully. Apple, Google, MS all keep changing their OS and browser behaviours all the time and cross platform devs need to adapt to those things continuously.

Re: We're forking Flutter

#515

The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application. With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps. Java, C#, Rust, C, C++, Go, Python are usable for more than one thing. I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usa…

Ruby is exactly as versatile as all those other languages you list. It was made before Rails was, and it can do everything eg Python can. It's not very popular anymore outside Rails but eg lots of people did APIs in Ruby using stuff like Sinatra. I personally did lots of CLI utilities in Ruby. It's really nice for stuff like that.

Ruby has plenty of other applications written in it, it definitely doesn't belong to the "one app" language list.

Re: We're forking Flutter

#516

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.

Why would an app not looking like a native app automatically be seen as badly implemented?

In my case there is another reason - if it looks cross platform it is probably taking up more resources than a native app.

Re: We're forking Flutter

#517
post #162

Earlier quoted context omitted.

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

Exactly: the number of users is just not a good way to measure this.

IMO, the entire number counting argument is beside the point. Workable dev count/user count ratio varies depending on circumstances. A better way would have been that the "in-house Flutter team is slow to accept outside contributions so I'm forking it".

EDIT: minor wording

Re: We're forking Flutter

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

I think author put incorrect words into the statement you are quoting. Flutter has much less mature environment, UI packages look good, but most are hot garbage without even unit tests. You can't trust even a single one if it doesn't have at least 5 active developers. They are drying like flies, no one maintains them, updates on time and Dart package manager doesn't help at all, makes things worse by having that system of requirements, versions. I used to work on a side project in Dart and Flutter and quickly fall in love, because i was able to write UI and backend code super quickly, but about 18 months later, I was spending more time maintaining packages that were dropped by original authors, updating, fixing conflicts between versions, and this was the reason I simply rewrote everything back to Java, even frontend to PrimeFaces (: Nothing broke by itself since early 2021.

Even Google dropped 3 packages I used in my projects. Including Dart Angular, they archived it 7 months after promising in AMA they will maintain it for a decade ahead (: They also abandoned their flutter charts library, it stopped working in newer versions of Dart and community had to fork it, they made like 80 forks in a week.

I think this is the problem author is trying to say, not Flutter as the framework, but as the general ecosystem that's consistent and provides at least somewhat positive experience using it. Google is neglecting it.

Re: We're forking Flutter

#519
post #405

Earlier quoted context omitted.

> So that means one has to target both GTK and Qt to be native on Linux. Incorrect. Target one or the other, not both.

How is Qt within a GNOME or Xfce environment any more "native" than Qt on Windows or Mac? You have reduced the definition of "native" to merely compatible with X11/Wayland (that's the only common denominator). Well now, Tk, FLTK, Swing, and even Wine are all native.

Both Qt and GTK have facilities for integrating into each other’s desktop environments (see [1]). Sometimes they blend in nicely, sometimes they stand out a bit, but I think it works out pretty okay.

[1]: https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK...

Re: We're forking Flutter

#520

Earlier quoted context omitted.

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

I suppose this problem is timeless, back when I was active in the PHP community it was a long-running joke that people who "graduated" to committing to the actual php source (in C) were not doing web development work anymore. And I suppose it was actually true for the majority. On the other hand, designing language features wasn't really related to using it for web work.
Post reply on HN