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

621–630 of 748 posts

Re: We're forking Flutter

#621

Post by divan »

jwells89 wrote: post #308
no_carrier wrote: post #285

Earlier quoted context omitted.

I don't think people are able to tell a Flutter app from any other cross platform/web framework. They just think they can.

It’s more difficult to distinguish if an app is Flutter or some other cross platform framework, but “native or not” is very easy on iOS. Even React Native, which is the least foreign, has tells. On Android it’s more difficult, partially because it’s kind of like Windows where Google/Microsoft uses 50 separate reimplementations of Material/Fluent and there’s no consistency to be found anywhere.

Ah, so we talking about two different things here:

a) with any given UI design, distinguishing if it's implemented using native UI framework or with Flutter

b) Flutter app providing 100% indentical look&feel to Cupertino/MaterialDesign/WinForms/Cocoa/etc.

I was talking about a). Assuming that the app developer wants to have a consistent app design across platforms, which probably came from a design department – there is virtually no way to distinguish. Ultimately, it's just a bunch of pixels spit out onto the framebuffer.

Re: We're forking Flutter

#622

Post by tauntz »

nottorp wrote: post #512
dwaite wrote: post #477

Earlier quoted context omitted.

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

It's not specific nor limited to javascript. The term "canvas" in this context is much older and seems to be used across many platforms.

Random examples from the (desktop) Java/Android/iOS world where the same semantics is used:

https://docs.oracle.com/javase/8/docs/api/java/awt/Canvas.ht...

https://developer.android.com/reference/android/graphics/Can...

https://developer.apple.com/documentation/SwiftUI/Canvas

Re: We're forking Flutter

#623

Post by exusn »

jwells89 wrote: post #323
knifie_spoonie wrote: post #319

Earlier quoted context omitted.

I'm really curious what the specific tells are. Do you have any specific examples? When using the apps on my iPhone, I just don't see how I could tell the difference.

For React Native it’s common for navigation to be weird compared to UIKit/SwiftUI apps. Also common for things like padding/margins to be off since standard layout facilities aren’t being used, and devs of RN apps will often visually customize controls (web style) that native devs don’t. For Flutter, the most visually obvious thing (aside from usually using Material Design) is that its animation curves are all totall…

Yep, same. For me the animations are a dead giveaway if an app is using flutter. That, and the scrolling just feels _off_ in a way I can't quite describe and is a little clunky.

I had been building stuff with flutter for a while when GPay migrated to it and I could straightaway tell from the performance that it was flutter.

Re: We're forking Flutter

#624

Post by justmarc »

Anon1096 wrote: post #453
jwells89 wrote: post #303

Earlier quoted context omitted.

Not all non-native-looking apps are badly implemented, but a huge number of apps that use cross-platform frameworks do so primarily as a means to cut costs because the goal is to make development as cheap as possible, and that shows in other aspects of these apps too. This creates an association between cheap/lazy apps and cross platform UI frameworks. It’s kind of like the difference between VS Code and MS Teams. Sa…

You could not be further from the truth regarding the size of the Teams vs VS Code teams. Teams has multiple times more developers, it's not a problem of funding that makes it suck.

Sometimes the bigger the team, the messier it gets and quality suffers greatly.

Re: We're forking Flutter

#625

Post by okwhateverdude »

lopatin wrote: post #337
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…

> we do not want, or intend, to fork the Flutter community. I can't reconcile that statement with the rest of the blog post. Good intentions aside, this is exactly what they are on the path to doing. From the post: > By forking Flutter, we get to decide what gets merged. I'll allow myself to be naively blunt since I just learned of this and I don't have a stake in this battle, but it seems like a nice little coup att…

> nice little coup attempt that Google can squash

I mean, Google could also punt and let Flutter die. They've killed greater investments for less.

Re: We're forking Flutter

#626

Post by account42 »

notpushkin wrote: post #519
epcoa wrote: post #405

Earlier quoted context omitted.

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

GTK doesn't much care about integrating into a Qt environment and doesn't really implement anything to make that work besides in some cases implementing the same Freedesktop standards. Even for basic things like the look of widgets you need a style that has implementations for GTK - there is no compatibility layer to use Qt styles. Gnomies in general don't care about anything outside their world.

The other way around is a bit better, e.g. there is QGtkStyle but AFAIK it is stuck at GTK2 and does not support using GTK3 styles. Still, behavior between GTK and Qt applications is very noticeably different.

It would be great if there was a shared ABI applications could use but GUI toolkits are too complicated for this to be feasible.

Re: We're forking Flutter

#627

Post by lukepighetti »

thiht wrote: post #592

> How many Flutter developers exist in the world, today? My guess is that it's on the order of 1,000,000 developers. I have a hard time taking this number seriously, that sounds grossly exaggerated. Are there parts of the world where people actually use Flutter? Even their showcase is pretty light and a bit deceptive.

Flutter is weak in North America but extremely strong in LatAm / Europe / India / Africa

Re: We're forking Flutter

#628

Post by jamil7 »

deergomoo wrote: post #215
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 th…

I noticed the SNCF Connect app for France's rail was using it in their showcase which explains why the scroll views are so weird and busted feeling. They still stutter on a new iPhone. As a native iOS developer I'm somewhat biased and a lot of people likely don't care but it still feels off to me even for apps that use a complete custom design. I hope they can optmise away those kind of issues more as it's IMO always better to have alternatives.

Side note: Is anyone using Flutter just for Android? I'm kind of tempted to try this as dealing with the Android build system and packaging is bit of a pain, despite Kotlin and Compose being quite nice.

Re: We're forking Flutter

#629

Post by account42 »

divan wrote: post #620
account42 wrote: post #610

Earlier quoted context omitted.

Existing food delivery apps are not only indexable by google but actively make sure to spam the top google results for all possible food related searches. You couldn't have choosen a better example to disprove your argument if you tried.

I think you're talking about AdWords contextual ads paid by the food delivery companies, not about Google indexing apps.

You may think that but that doesn't make it reality.

I think you are grasping at straws because you know you are wrong.

Re: We're forking Flutter

#630

Post by eskibars »

eskibars wrote: post #466
zX41ZdbW wrote: post #397

Earlier quoted context omitted.

I have statistics about real team size behind open-source repositories, and it is exceedingly rare to be larger than 50: https://play.clickhouse.com/play?user=play#U0VMRUNUIHJlcG9fb... For comparison, my open-source product has around 20..30 according to the monthly stats (I want these numbers to be higher, though): https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvU3Rhc...

This is significantly undercounting in at least several cases I know of. e.g. I was employed by Elastic and Kong and in both cases, the number of developers employed by the company to work on these projects was several multiples the size reported here

Ah, I now see why: I hadn't really looked at the query, but now that I have, here are some of the problems:

1. Using median is a problem for many projects because many often start off (sometimes for years) with only a few developers before they really take off. The median() number for Elasticsearch was 28, but the max() is 49, which I suspect is closer to the current number.

2. Not everybody uses a pull request flow, and not everyone working on a project is a developer. You could have product managers, technical writers, engineering managers, etc, all working on a project and not opening PRs and you can have users just directly adding commits, especially when a project is young. The original query here for the kong/kong project shows a team size of 6, but if you remove event_type = 'PullRequestEvent' and switch to max(), you get 33.

3. Sometimes, parts of the project are kind of "elsewhere." e.g. Elastic employed a number of Lucene committers to help move Lucene along, Kong employed a number of folks that would e.g. commit/maintain OpenResty plugins which got incorporated in the build system, the docs live in separate repos in both cases, etc.

Post reply on HN