> 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…
We're forking Flutter
511–520 of 748 posts
Re: We're forking Flutter
#512Earlier 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.
Frame buffer? Canvas is the javascript term.
Re: We're forking Flutter
#513> 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…
No wonder it's not accurate.
Re: We're forking Flutter
#514Re: We're forking Flutter
#515The 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.
Re: We're forking Flutter
#516Earlier 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?
Re: We're forking Flutter
#517Earlier 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.
EDIT: minor wording
Re: We're forking Flutter
#518> 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…
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
#519Earlier 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.
[1]: https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK...
Re: We're forking Flutter
#520Earlier 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