> 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 replacement (just configuring FVM - Flutter Version Manager):
Configure .fvmrc to use Flock:
{
"flutter": "master",
"flutterUrl": "https://github.com/Flutter-Foundation/flutter.git"
}
Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. And the frustration described in the post is felt by many CTOs and developers. Especially those who use Flutter for desktop and web. Flutter provides an amazing experience for desktop apps, and precisely because of that, it feels so frustrating when you stumble upon some stupid bug that has been open for a year or two and never gets prioritized. Usually, it's nothing critical, but still requires workarounds and wasting time.
I don't know, the idea of Flock sounds good, the main question is engaging the community. Hopefully, the author (who seem to be an ex-Flutter team member himself) have a good grasp on the state of the community.
Wishing luck to the project and going to keep an eye on the progress.
> 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 the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.
Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.
Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.
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 people just don’t care about platform idioms, and b. the choice is often a non-native app or no app at all.
Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter at all and flutter even offers a pretty good cupertino scaffold package that does this animation.
"cupertino" is the name of a Flutter widget set, not of the native platform controls or L&F.
Few Flutter apps are going to use cupertino because the whole goal of using Flutter is to create cross platform codebases to save development effort. To use an alternative widget set per platform is a huge amount of additional work, and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.
The two things that stick out the most to me are navigation behavior and text fields. Cross platform frameworks seldom get either right, with react native being particularly bad on the navigation front.
There are variances between Apple’s apps but they’re all using some combination of UIKit and SwiftUI regardless which limits how “wrong” they can be.
You’re completely right, but that doesn’t change the fact that I think it’s a bad idea. For a company that used to care so much about user experience, Apple has been throwing a lot of it out the window in recent years.
Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.
You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technical reasons why, but when you talk about the annoyances it is easier.
I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC
In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for desktop and phone but not so for Windows and Android, so you have to make a choice at that point.
> The vast majority of people said they wanted apps to act consistently across devices
You shouldn’t trust what users say they want. It many times doesn’t correlate with what they want. Certainly, I would try and figure out what they mean with “act consistently”. My suspicion (for which I have zero evidence) is that they’re more talking about high-level similarity than about nitty-gritty details such as how many milliseconds to hold your finger down to select and edit text, how scrolling works, etc.
Also, I suspect they want devices to act constantly across apps, too: copy-paste should work, text editing should behave identically, sharing controls should be the same, etc.
In the current world (and, I think, in any world where there is competition in any form between platforms), they cannot get both, so then, it boils down to what is more important.
For me, that’s platform consistency. For example, I find it easier to get used to text editing being different on a phone and on a laptop than to get used to a zillion minor inconveniences/annoyances in typing and editing behavior between apps.
I also find it less of a problem if text and emoji look slightly different on a different device than when they look slightly different between apps.
If you have zero evidence against the mountains of evidence I do have, why should I be convinced of your argument. It seems like it is you who are talking subjectively about what you want and then applying that to everyone else.
I find it very hard to believe that majority of people prefer app consistency over platform consistency.
One example, I'm pretty sure there are thousands more: Why does every UI detail, except the logo, of Spotify looks and feels different in Android, Android Auto and PC/laptop? Because Spotify did not study what the market wants?
Spotify looks much similar between devices than it does to any specific platform. Does it use Material on Android and Fluent on Windows? No, it uses the same sort of styling on both. Don't mistake UI changes for screen size responsiveness, for actual platform specific nativity.
> The vast majority of people said they wanted apps to act consistently across devices
... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use).
Certainly there is some overlap between look & act: a platform-native "dropdown menu" looks and acts a little differently on Windows vs Android vs iOS. But I think these differences are not in the majority, and when users say they want apps to "act consistently" across platforms, you an absolutely achieve that with native UI controls, and it's not even that difficult.
This is a big problem I've run into when doing user studies myself: you need to be very precise with your language when asking users questions, and even then you often need to dig in and ask for details about what they mean by their answer. And of course having visual examples and functional mockups for users to play with helps a ton.
Another problem is the leading nature of questions you might ask during a user study: if you simply say "do you think it's better if the app acts consistently across platforms", of course users are going to say "yes". Saying "no" to that question feels kinda stupid, TBH. But if you were to give a user an iPhone and Android phone, with the same app, using native controls on both platforms, and ask them if you believe that the apps "act consistently" with each other, users are probably going to say "yes", as long as the design and UX of the apps in general are consistent with each other.
(And even that's a contrived test: very few people use both an iPhone and Android phone regularly!)
You can achieve them with native controls but only at the bottom-most layer, if you actually want consistency. Spotify for example does not use Material on Android, Human Design Guidelines on Apple, and Fluent on Windows (well, they use Electron, bypassing native desktop entirely), they use their own custom controls that may at the very bottom layer be based on native text inputs, but they rebuilt all the actual UI stuff from scratch to achieve a unified look and act.
This is all well and good but the people I see on HN are ones that say that the app should actually look native on each platform, ie Material on Android etc. This opinion is what I'm pushing back on, not the fact that ctrl + C works on Windows and CMD + C works on Mac.
Of course, this is the reason why cross platform frameworks are so popular, if you're already gonna have to rewrite the UI for every platform, why not just do it once and save yourself the effort? After all, users won't care, as they've shown, because they care much more about new features coming out. There are always tradeoffs because time is finite.
> This is a big problem I've run into when doing user studies myself
Sigh, do you really think that all of these weren't considered when we did user studies? This is like 101 material, frankly almost insulting to imply that we didn't, therefore it can justify your priors, even though I agree with your points to some extent as said before.
It's not the end users that care about the uniformity but the fact the corporate design team wants there to be uniformity across all their platforms they support. This is part of branding and user experience. I'm not arguing for or against, just stating that is where the push for this comes from. It would make support, for example, easier, if all versions of your app user experience were similar.
This is very true, and it's a PITA when the corporate design team doesn't know anything about mobile design and thinks mobile apps are just "Honey, I shrunk the web app" with some Figma plugins to help. It can be an uphill battle to get them to compromise.
It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.
It doesn't seem to mention it being done against anyone's will. It's definitely true that a company can save money by only needing to maintain one set of help instruction screenshots, for example.
Ever since the release of the M1, the number of Android users who now use Macbooks as their laptop has sharply increased. Even moreso for work purposes.
Hello! I use three platforms on a daily basis. I vastly prefer my apps to be reasonably consistent with themselves rather than trying too hard to adhere to the platform.
My wife is on two. Most of my friends are on either two or three. In fact, I'm pretty sure my parents and a few coworkers are the only people I know who are exclusively on one platform.
Many (most?) people don't have a clue as to what the particulars of any given platform even are. They know how to get around in each app they use, and maybe the web browser, and that's it. Lots of gestures go completely unused.
> I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms.
It's not even a single person that has them, but I think we have all had the experience of family or friends that need assistance with something but they have a different type of phone whose organization and workflow is completely different because it's native. You literally can't help in this scenario without having physical access to the device.
I've genuinely never heard of such annoyances from actual users (at least not from most users, who aren't power users, and even then, not even from the power users), and most cross platform frameworks already hook into the native APIs like for the back button, so it'd work the same either way.
Out of interest, do you know many seriously vision-impared people?
Windows, and Mac OS X in particular, have quite good support for accessibility if you use their built-in GUI systems, and unified UIs are often (not always, vscode and chrome are quite good, for example), very bad, sometimes just a black square as far as accessibility goes.
Many cross platform frameworks have good accessibility support, not sure what that has to do with native platforms, as the cross platform solutions simply hook into the native platform accessibility APIs anyway.
I didn't know flutter had such good support, and I'm very happy to hear about it!
Unfortunately, most cross-platform frameworks have awful accessibility support, I've looked at various in the past and just found failure after failure. I am now going to look harder at flutter.
People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.)
It is exceedingly rare for the multiple devices to span the UI toolkits of more than one or two company-platform. For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
Regardless, "unified UI" doesn't mean it can't use native controls. More important from a UX perspective is that controls are in the same places and behave similarly, and that the app is organized in a similar manner, plus or minus what might naturally change because of differences in screen size and input method. And that's another useful point to make too: mobile, tablet, and desktop experiences are often quite different, and that's normal and expected at this point.
Another consideration: it's a lot more difficult to make an accessible app when you draw your own custom UI controls with your own custom behavior. If you use the native UI controls, you get a lot of the accessibility features for free, and have to do much less work to make sure everything works for people who are vision or mobility impaired. From what I understand after reading about blind people's experiences on various platforms, most companies that do custom UI don't bother, and the accessibility of their apps is atrocious.
I think you made the same points twice so refer to my other reply regarding your first few paragraphs.
> For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
I have not seen evidence among normal people that this is true, given that the most popular apps all have custom UIs that don't necessarily follow Apple's HIG, TikTok for example. Regardless, the point is that if you're making an app for every platform like iOS, Android, Windows etc, you must make a choice lest you exclude all non-Apple users for example. ByteDance does therefore indeed use Flutter, based on this (at least in some capacity).
> mobile, tablet, and desktop experiences are often quite different
Don't conflate unified UI to mean non responsiveness. Look at Spotify, their UI is essentially the same in design except it is responsive among mobile, tablet and desktop, all while not looking native at all on any of them.
Regarding accessibility, many frameworks can be robust in that simply because they hook into the native implementation anyway, so I'm not sure where this trope of not having accessibility comes from. Here is Flutter's for example, with a dev in this thread also having talked about how they have one of the most robust implementations of accessibility that they have found among any framework: https://docs.flutter.dev/ui/accessibility-and-internationali...
I think the problem with the same app following native app idioms is that now the support and instructions behind that app will have to be different on every platform.
E.g., if you have Instagram on your iPhone, an Android user won’t be able to tell you “just click on this, this, then this to change your XYZ setting” because it will be in a different place than the Android app if developers follow native conventions 100% of the time.
The fact that Spotify or Instagram or any of those other platform-agnostic apps look and function the same on every platform is a huge benefit to practical usability.
I think the only time when nativeness matters is when you have an app that’s doing stuff that’s closer to being “low level” to operating system features. For example, an app that performs file system management, I don’t want that to have the exact same UI on Mac, Windows, and Linux, because those platforms have different conventions for where things go and how files are represented.
> 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 can smell a framework app.
> 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.
Do you only use Apple devices? That may be why, because statistically most of the world's population uses Windows and Android where there really isn't a concept of "native" because they each have a few different UI frameworks.
Do you hear people complain that __websites__ have different aesthetics?
I used to share your opinion but since the web I think it is great that designers can have original designs and I started to worry about more important things.
I agree. What doesn't get enough attention in these often dogmatic debates is that there are some native conventions that are hugely important for usability while others are mostly irrelevant.
E.g, I have to use a Java app on the Mac that uses Ctrl+V rather than Cmd+V for paste as well as other Windows/Linux keyboard conventions. This is extremely jarring.
Web apps never do that. Browsers are pretty good at using native conventions where it matters by default. Of course web devs sometimes go out of their way to vandalise the browser's perfectly good defaults - e.g. by overriding scrolling behaviour.
Surprisingly, some of Apple's own native apps (such as Numbers) break platform conventions in ways that makes the app extremely inconvenient to use.
The web is interesting because we never had rich components provided by the browser to begin with. Web applications have always had to draw everything but the most basic inputs themselves, and the design of web apps has evolved accordingly.
In an alternate universe, where web apps were embraced by the platform from the start rather than something people had to shoehorn into a document sharing mechanism, and we had rich components built-in, then yes I would probably be annoyed if people insisted on rolling their own versions. After all, I am annoyed when people use a span with a click handler instead of a proper anchor tag, because it usually breaks middle clicking or opening a link in a new tab—a platform convention I have internalised and expect to work.
Note this only applies to web apps, not sites. Much like how I do not have any problem that magazines don’t share a common layout.
> Of course, I recognise that, a. most people just don’t care about platform idioms
This is the big one. HN commenters are not representative of the average user. You'd have to specifically point out the differences for them to even notice, and even then they simply don't care.
Casual users do care about app behaving wrong, though.
If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave.
They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame of reference (vendor-supplied native apps).
Is there a concrete example of this? I still only hear this on HN where some mythical user gets annoyed about copying and pasting (most apps don't allow that, even, like TikTok or Instagram, which are the apps where most users spend the most time). Like the sibling commenter, I only have seen whether the app does what they want or it doesn't, most don't notice any annoyances unless they're really looking for them, which they're not.
> I still only hear this on HN where some mythical user gets annoyed about copying and pasting
Perhaps they're not complaining because they've just accepted that it probably doesn't work and so don't even try anymore.
My SO has stopped trying to copy/pasting stuff, I now always just get screenshots, both from mobile and her PC.
At work, almost none of the customers I interact with copy/paste stuff, they send screenshots as well. Like, "can you send me the order number?" will result in a screenshot of the order number control, or often just the whole order window.
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 built the understanding that users dislike non-native UIs?
I've built apps with pretty high retention rate so even if they're annoyed, it doesn't seem like they really stop using them. Mostly though, based on user feedback we collected, not once have I heard anything about UI complaints. It really feels like this is a common refrain on HN about what HNers think happens in theory versus what actually happens in reality wrt user preferences.
Note, this has nothing to do with your app or this specific discussed GUI, but this is something I have noticed over time...
I think that what is commonly seen by devs as complaining and being overly concerned with details that don't matter is instead a some of the time advocacy for doing things the right way for the sake of it. It is totally possible to build things that meet the bare minimum requirements for user retention and for people to not complain, but that doesn't mean that it is optimal. You can build Soviet style housing blocks that people live in that are completely functional and that no one will have any problem with, but the quality of life is degraded as opposed to what could have been built.
It can be tough seeing through the grumpy nerd 'I want it my way because my way is best' and finding what is actually 'this is a good thing that we should be doing, and if we did there would be a marked improvement for everyone', but I would not forsake one due to the other.
It's more than there is no evidence of an issue, so why pretend that there is? The "right" way is entirely subjective, unless you can give me some objective criteria for what it should be.
The issue in this case is pretty plainly that the application does not subscribe to the conventions of its host UI. I'm sure there is no objective reason why we need to conform to any convention, except that there is one.
Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.
Perhaps so, as different cultures have different tastes anyway. That you don't like Soviet styles is no indication of whether people in the Union did or didn't like them.
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. Same company, same underlying technology (Electron), but Code is good while Teams is awful because MS invests so much more in Code. Even so, Teams-type apps are what tends to come to mind when people think of Electron apps because those are so much more common.
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.
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 happen to have created a great native experience. And since most apps don't, I don't use them, and I don't have a lot of apps as a result.
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.
As an on-again off-again (currently off-again) cross-platform app developer, I always want my app to look like it fits in with the rest of the apps on whatever platform it's deployed to.
As a user, I hate it when some app developer thinks they're cute and wants to skin an app differently or draw their own ad-hoc widgets.
Developers who think that way have no clue what their users want. Most iOS users want a native experience, not something else. When I see an app that doesn't have that, I quickly lose interest. Having the app look the same on all platforms is a dumb idea to start with.
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.
You still have to deal with the Android build system, `flutter new` just generates initial config for it and all the other necessary metadata (and that config can change between versions - I ended up manually diffing the generated stuff against a new app every time I upgraded).
At some point I made the mistake of not touching the code for too long and upgrading Android Studio when suggested, and I was never able to (find the time needed to) get that app working again.
> 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.
Typically people just make the app look and work the same in all platforms, like how you might expect a responsive web app to be like; no one is implementing Notion with a platform specific UI, for example, using Apple stuff on Apple devices or Windows stuff on Windows devices.
You may notice that the first reference is from java, and i bet js lifted it from there. They may have been aware of java because they lifted the name too.
That is good to hear and hopefully gets fixed. It has been some years now, but I did use flutter for some toy projects and liked using it - I am used to using ReactJS I found there was a lot of transitive knowledge coming from that background.
Ultimately what dissuaded me from pursuing it for any bigger projects is a lack of examples of great looking production apps with complex requirements. When I was looking, I was seeing a lot of CRUD apps - display a form, click an upload button, ect. This was probably 2018/2019 when I was taking a serious look at it.
All of that is to say: Quality app showcases do matter for whether or not devs will trust a solution enough to pull the trigger.
I don't know how to fix the showcase problem. With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible. And there are zero incentives for developers to send their apps for screenshots. You just ship the release and move on to the next tasks.
I also discovered Flutter in 2018, and it kind brought joy into UI programming for me. I rewrote all web apps I had with Flutter and published a bunch of mobile apps, but the coolest thing is that I routinely make apps for my own (or my team's) use.
For me, Flutter lowered the costs of UI app development so much that I could just spend a weekend making some neat, small, practical tool for my own needs. I really love making these "private" apps – no need to care about all corner cases for all users, no need to polish design for all screen sizes/font sizes. Don't even need to be released (TestFlight at max, if doing it for a team). It's just fun, and I wish more developers could have the same experience.
This is trivial for any team that provides a framework/platform and spends any amount of time engaged with their customers - you know who your prestige customers are and you show off examples of the products they have built with it. The state of the showcase is just reinforcing the points made by the OP.
> With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible.
I think they're referring to the extra frame of latency when scrolling on Android. But then again, I've literally never heard anyone complain about that, I honestly don't think anyone notices, I believe the GitHub issue had to use a slow motion camera to even capture the issue.
Sorry, but do you really develop your software as a professional engineer based on "I heard X from few people"? With all the bias and filtering your brain does for this kind of "metric"?
Do you not? Engineering is a tool for solving human problems. If humans don't have a problem, then there's nothing to solve. Engineering is not the end in itself but the means to an end.
A lot of users do care for fit and finish, but stick around with crappy UI because it’s not worth rage-quitting over.
They do move when better UI + same-ish functionality comes along.
The one sort-of exception to this is Enterprise Sales, where the people buying the software don’t always use it. But even there, corporate purchasers do get flak in annual reviews / feedback cycles for especially crappy enterprise software — so even there, especially crappy UI will catch up with you.
But the question is will they move from a Java UI to a native windows UI, all else being equal. What if the Java UI is better ? What if the Java application is better
I think you are correct, but I think your example is a bad one. Most people do not have a realistic (their employer will use it at work, it even occurs to them that they could use something else) alternative to MS Office so will use it whatever MS does.
I miss the days when applications had their own look and feel. If your idea of great design is identical rectangles to all the other apps, I guess Winforms solved that use case 20 years go.
It’s perfectly possible to still have a unique look and feel without completely forsaking all the platform affordances. You get a lot of stuff for free or very cheap building using the platform toolkits: stuff that people internalise and expect to work without even realising it. I think it’s a bad idea to throw that all away.
Just like a lot of the "web application packaged as mobile app" frameworks did in the past, except with ugly iOS styling that also completely mismatched the expected navigational patterns.
What's worse, there are new applications with custom look and feel that do the same navigational sins today
I think people might be talking past each other on this issue. If you are on one platform only, then yes having apps behave the same is nice for muscle memory. However, if you're using multiple devices and platforms, then I want Slack to work the same regardless of device, I don't want iOS native navigation on the iPhone and Windows native navigation on the laptop.
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
I was a Flutter early adopter going on for like 7 years ago now, and Flutter has its place, but I don't know if I could repeat your sentiment with a straight face. Especially when comparing it to Qt.
flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....
If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean impossible, design limitations of the web platform that in some cases fundamentally cannot be relaxed and in others are very unlikely ever to be. With this direction, scrolling will never be good, text rendering will never be perfect, input and manipulation will never be acceptable, links will never work properly.
Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.
When you want to draw this distinction: most web apps will still suffer heavily for many users if they use Flutter. To begin with, few web apps don’t use text, scrolling, or form fields. Games are almost the only thing that may not suffer, or only barely suffer. But beyond that: well, that’s what they say its purpose is, but at least two of the three times I’ve encountered Flutter in the wild on the web, it was inappropriate, and frustrating; regular DOM should certainly have been used. (The third, I’ve forgotten what it was. It was probably similarly inappropriate.)
Skia is not the bottleneck. The web platform is. Scrolling is limited on two counts: ① what browsers expose in events is insufficient to match the native implementation (which varies by platform) in scrolling amounts, overscroll behaviour, and related things; and ② the browser is a compositor, and your code will never get access to that layer, because it’s way too deep in performance-, security- and implementation-detail–land, so you’ll always be stuck at least sometimes at least one frame behind “native”, and janky.
Could you be more specific with what the browsers aren't exposing properly? Because in my experience, targeting WebGL+WebAssembly is pretty much exactly the same as targeting OpenGL+GLFW. I use my own renderer made with bare OpenGL + C++ though, not Flutter. All the things you have mentioned (scroll amount, overscroll behavior) are under the control of the GUI library and don't have much to do with what the browser exposes. The compositing of the whole scene is done by the gui library itself
I use Firefox, Sway, Linux, laptop with precise touchpad.
Normally, I get smooth scrolling at such-and-such a rate of pixels-per-centimetre, with momentum so-and-so, and since comparatively recently, particular overscroll behaviour.
On that site, I get janky scrolling at a somewhat slower rate, with no momentum, and no overscroll. (… and scrolling leftwards in the carousel triggers go-back-a-page rather than scrolling left, so you need to scroll right a little first to “unstick” it, but I believe this is something Flutter could have worked around.) It’s painful. Very painful.
It’s not possible to fix this within the scope of browser mouse events. They’re just the wrong primitive. The consequence is that you can only get native scroll behaviour if you use an actual scrolling area. Which you could do, with mild compromise to the pure-canvas approach, just an invisible one and watch what happens with it, rather than paying attention to scroll events. And that’s pretty much the approach you need to use to get good results: compromise on pure-canvas, and do bits and pieces with actual DOM. For scrolling. For links. For images. For text. For inputs. Oh… huh, look at that, we actually just want real DOM stuff everywhere. Fancy that.
Now you might not immediately get such a bad experience for scrolling: I seem to recall hearing that Safari on macOS basically implements inertia before sending the events, and sends the events with inertia applied. That solves some problems, but causes others.
Actually, I meant two distinct things by “overscroll behaviour”:
① Does it let you scroll past 100% a little and then pull it back, as is increasingly normal, or show some indicator that you’ve reached the end, like Android has historically done, or just do nothing, like all computers historically did?
② Scroll chaining, the CSS overscroll-behavior property, to do with nesting scrolling areas. And note that different platforms behave differently. If you do pure-canvas rendering, you’re stuck: the browser has some of the details needed (and is unlikely to ever tell them: they’re involved implementation detail that varies by platform), and you have some of the details needed, and you can’t really collaborate, it’s just not a good mixture.
When I speak of the browser being a compositor, I refer to how scrolling is no longer implemented in a blocking fashion in the UI thread; these days it’s in a different thread, so that it can implement viewport scrolling independently of content rendering, in order to maintain consistent frame rate even in the presence of slow drawing. Also to do various other tricks to avoid missing frames, mostly platform-specific and involved. Web content will never get that power.
Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?
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.
This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately.
When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far.
2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinion, of course. And yet, as a developer, I care about using the right tool for the right task, and no amount of browser engine optimization can change the fact that XML-based markup language is not the right tool for modern performant cross-platforms UIs.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing.
Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.
Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within <p>. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know.
So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
> 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 designer resources needed to get there.
> 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.
I’d much prefer they’ve gone with their own design system. People are already used to bespoke ones (web), badly done ones just remind me of scammy sites.
but flutter was probably sold internally as a trojan into ios dev experience. the carrot was multiplatform... and to sell it they needed to at least market that it was "true multiplatform" with native look. which is ironic since they go out of their way to make it pain to build to both in the same app
> 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 attempt that Google can squash by putting more resources into Flutter if they feel the pressure.
>Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
I agree with you that Flutter has been a boon for cross platform development, but to say it's impossible to tell you're using a Flutter app is a bit of an exaggeration. I have no problem identifying Flutter apps. Not that I care as they often have a genuinely nice UI and are performant.
I worked on the GPay flutter rewrite and our standard for accessibility was higher than almost any other app I've seen, and was a significant amount of effort spent on that. What accessibility shortcomings does flutter have?
This may be a silly question, but how do I install the Google Pay app on my iPhone?
I'd like to try it out since it's the first app listed in the Flutter Showcase, people keep mentioning it in this thread, and it probably works as well as a Flutter app can, given that it's first-party from Google.
But when I search for it on the App Store, it's nowhere to be found (or at least not in the first 20 results).
It's only for the Indian market. As Google often does, they released Google Wallet for the US market. But that's not a failure of Flutter itself of course, only internal Google politics.
Google pay was never able to fix the pre-compiled animation rendering issue on iOS where the first transition or animation is always janky and then it gets cached and no longer has jank.
Can you elaborate? What's missing that makes you feel confident saying "complete lack of" despite well-documented accessibility functionality (including testing for accessibility)? [1]
How do you do that? I just opened my phone, and the last app I used was a food delivery app.
How can I figure out if it's a Flutter app or a native one?
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.
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 totally different from those of UIKit/SwiftUI and interact with gestures differently. The Cupertino theme is a poor facsimile of UIKit and lands squarely in the uncanny valley, which is arguably worse than Material Design. Flutter on iOS also tends to hitch where UIKit/SwiftUI don’t.
There's likely things we missed but we'd love to find examples you might have. We try to be scientific as much as we can https://github.com/flutter/flutter/pull/122275 [coincidentally a community contribution from someone who didn't have to fork :)]
Disclaimer: used to work on some of these animations
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.
There are obvious tells an app is non-native. One of the easiest is to view the settings screen. Setting screens on native apps usually all look the same. I haven't seen one Flutter app that has replicated it.
Haha. Oh, most people know! They might not be knowing it’s Flutter to be specific but they sure know it’s some hybrid/non-native crap.
I recently started using Ente migrating from Authy and goodness it feels and looks awful. I wish 2FAS had a desktop app. There was a native alternative that allows exporting codes. (This is not against Ente devs. I am sure they are a small team bringing out a FOSS product. This is just my preference)
I can’t imagine using Flutter for desktop development if only because like most newer UI frameworks, it’s mobile focused and doesn’t come with important desktop widgets like tableviews/datagrids and treeviews.
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.
Depends on what's being developed, I guess. No tables/trees is probably ok for a lot of lighter end-user sorts of apps but doing without them for many desktop-first apps and utilities would be rough. Desktop file managers, media library apps, and email apps for example would be quite a lot less useful without multi-column tables at the minimum.
I almost never use email on anything but my phone, and Gmail doesn't use a table. They do some tree stuff for the conversation threads, but conversation threads are obnoxious anyway and I have no idea why anyone likes them, they don't reflect face to face conversations well and always create mistakes where someone forgets to reply to all.
I've replaced a lot of tables in my apps with modal dialog UIs, it's nice to have them behave exactly the same on mobile and web, to not have any risk of mistakes due to filling in a box on the wrong row because the label is too far from the box, and it's just generally more pleasant for us non-ADHDers without very good native multthreading support in our minds.
Android style UI is all about encapsulation and reducing the mental context window to the bare minimum, and it really makes a lot of desktop stuff look pretty clunky and confusing by comparison.
VS Code would definitely suffer a lot without the sidebar tree view though, and it does seem like a lot of people prefer the more open instant access to everything that a table provides, rather than clicking through dialogs.
This is something I have a difficult time agreeing on. I expect a certain level of information density and configurability in desktop UIs, which shoehorned mobile-style UIs don't do well to provide. Deep modality is also a peeve; on desktop there's often no benefit to burying things in mulitple layers of modals — within reason, the most important things should never be more than one click away and great consideration should be put into putting upwards of 2 clicks between the user and their destination.
That said, I do think it's fine to have a simplified mobile-ish UI as an option, but it shouldn't come at the cost of more classical desktop style layouts for those who can leverage them well.
As a sidenote, this is part of why apps like the mac version of Apple Mail and Thunderbird have a considerable number of hardcore adherents, particularly among power users.
There's a number of users who can really make great use of the power user tools, but adding multiple UI options can greatly increase work, because a fully modal workflow might need a completely different frontend, and some apps are meant for the mass market.
Degrading the experience for the majority just to make things better for the power users doesn't seem like it's always the best plan unless you're specifically targeting power users.
In the extreme case, UI for power users can result in production databases being destroyed, or someone getting served food allergens because the menu system made it easy to assign wrong items to wrong customers, or someone's entire family photo collection getting deleted by a single command.
My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them.
A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of abstraction you put on top of that hackish foundation, you are still running it in the program (browser) designed to show text. So you can select buttons, navigation controls, images, sound players, etc. And it feels very native to web users.
But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. Sure, you can "opt-out" with recent CSS controls for selection, but it's again, a hack - the default choice of "everything is selectable" is made by default for you by the browser. What does it even mean - select button widget? Why would you enable this complicated selection functionality for your UI that allows users to select navigation buttons with a blue selection box? Of course, if your app needs this functionality - you can add it. But otherwise, it would be labeled as a very stupid UI choice. Yet, feels native to web.
Another example is zooming. Because UI apps written in web stack can't completely hide the fact that what they are doing is essentially trying to morph text primitives into complicated UI widgets (makes sense for 2024, right?), and the browser is essentially a text viewer, everything is zoomable and feels "native" to be able to zoom a web app. And yet, this rarely works as intended. In any other UI framework, making zoom functionality requires thinking about what and how you want to zoom and why. OS text size preferences are well handled by flutter, but sometimes you do want to add your own zoom functionality. In web though you just blindly zoom everything, often blowing off the layouts and that feels very "native" to web.
My point is, that I don't think UI frameworks should try to match the nativeness of web, especially when they start targeting the wasm platform. These couple of decades of proliferation of web frameworks built on top of HTML/JS/CSS should just wane in history as a dark period of software engineering.
> But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider.
You say "insanely stupid", I say wonderful.
Everything you apparently hate about the web is what makes it good for users. Content is primary, and my user agent can resize it, restyle it, copy it, extract it, link it, read it to a blind person...
If you want to make a binary blob app, just make that. Stop trying to break the web.
Yes, that's the most common response. I've heard stories about "how wonderful when you can select everything" multiple times, and that's, of course, just shows how human rationalization works.
And yet, this "feature" or "UI choice" is not even a choice. It's just a byproduct of using the wrong stack for the task. Like, nobody ever sat and asked, "Do we want our apps to have everything as a selectable feature?" before shipping this "feature". It just happened, and then, of course, millions of humans, having no actual choice over it, naturally rationalized that as a "wonderful" feature.
It didn't "just happen" the early architects of the web designed a system to make it easy to share and remix content and subsequent generations of companies and their UX designers have so far failed to fully claw back user freedoms.
Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.
Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...
Those are some of the most niche use cases I've ever heard, and that is stretching it even on HN, much less anyone in the non HN bubble. Things like screen readers work just fine on non browser apps that don't have selectable text, for example.
Copy-pasting UI elements to ask for help on support forums is absolutely not a niche use case. You're asking for a world of even more terrible screenshots in support channels. Truly cursed software.
Who exactly is copy pasting UI elements? I have literally never heard of anyone copy pasting UI elements of all things over just taking a screenshot of the page, so please provide an actual example. And even if you were able to copy and paste, how would you preserve the layout of the UI since only text is selectable?
Selecting everything is what every UI toolkit should support. In the 90s it may have been acceptable to show an error MessageBox with a non-selectable message but it shouldn't be acceptable today. What needs to be selectable is defined by users not developers and the union set of those requirements is "everything".
Browser zoom also only ever breaks if you are fighting the Browser's layout engine instead of embracing that. Just don't do that and it works fine.
Of course most web "apps" shouldn't be apps in the first place but if they must be "apps" at least stop reimplementing a crappier version fo the native browser functionality.
Bolt [1] and Bolt Food [2], for example. One of the apps is built with Flutter, another one is native. Can you tell which one and explain how you noticed it?
Bolt Food is on the showcase page, not Bolt itself, which would be odd not to add both if indeed they were both RN, so seems like one is RN and the other is not, which is basically what the above commenter was saying initially. None of what you said really invalidates their point, because again if you search for RN jobs for Bolt, why would you not also assume it's for the one on the showcase, ie, Bolt Food? Bolt is the company name after all, not just the app name.
You were right. After your comment, I went back to my friend at Bolt and asked again. Bolt Food is on RN, Bolt is native. The conversation we had about Flutter back then was about his other project and not Bolt Food.
The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)?
And then Android? Ironic then that Google is the one behind Flutter.
The concept of native outside of MacOS/iOS is pretty busted at this point. At best it just means something non-web.
Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.
Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.
Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system.
> Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there.
Except for Microsoft's numerous attempts to supplant it and the fact that the base OS doesn't even use it consistently for their own system. Microsoft's own File Explorer and Settings app that only had to live along with Control Panel for a decade, was that not native? They aren't "Win32".
If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. Nobody casually calls it USER though, and the bulk of people still targeting it do so through .NET these days via Winforms.
If native just means provided by the vendors base system, ok, but then if there are 10 different forms of it, other than the distribution issue there isn't some great intrinsic benefit over just targeting Qt or Flutter. Especially when someone like Microsoft can't settle on a consistent design language through the years.
> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.
I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.
But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.
The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent.
Microsoft officially refers to that API as Native System Services in the documentation for the DDK.
Microsoft’s docs are a self-contradictory tangled incomplete and sometimes even downright erroneous mess, I wouldn’t put too much stock in what they say.
If I say “CreateFile is the Win32 API analog of NtCreateFile in the NT native API”, everyone experienced with low-level Windows development will know what I am talking about. If I started talking about “Native System Services”, I’m not sure as many would.
Similarly, the distinction between APIs which are easy to call from C code (and simpler FFI frameworks from scripting languages, e.g. libffi) and COM/Automation/.Net/WinRT APIs which are a lot more difficult to use from C (as opposed to C++), and which require more advanced FFI support, is still important in Windows development (or at least some parts of it.) And in practice the term “Win32 API” is often defined to exclude those higher-level harder-to-call-from-plain-old-C APIs.
It goes back to the original design of Windows NT, where you had a primary environment subsystem (Win32), secondary environment subsystems (OS/2 and POSIX), and integral subsystems (local security authority, session manager, etc). The primary environment subsystem is still called Win32, and the Win32 API is its public API. (It also has private APIs, most notably the CSRSS LPC interface, but that’s unstable from version to version.). As I said “Windows API” is insufficiently specific because (especially nowadays) Windows has lots of other APIs. WinRT and Win32 are both Windows APIs but very different. WinRT is largely built on top of Win32, but some documented WinRT APIs are built on undocumented Win32 APIs, leaving WinRT the only officially supported API to access certain functions.
Microsoft intentionally didn’t rename Win32 to Win64 when they added 64-bit support because it is 99% the same API just with some highly regular changes (mainly widening pointers). By contrast, Win32 was a much more radical change to Win16 - the Win16 API directly incorporates notions of segmented memory, which it uses to implement movable memory blocks (rather similar to Classic MacOS, albeit that did it in a 24/32-bit flat memory model rather than a 16-bit segmented one). Microsoft could have done a more straightforward port of Win16 to 32-bit x86, e.g. using a 32-bit segmented memory model instead of 32-bit flat memory, keeping movable memory; but (thankfully) they didn’t. It would have made it a lot harder to move to 64-bit or non-x86 platforms.
GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough options and I used the former for years.
GTK itself isn't even a well defined target.
And GTK3 apps of which there are plenty do not appear native in a modern GNOME desktop much more so than a decent Qt app does.
The thing is that people in the real world talk about Linux support for an app, as in Desktop Linux support, and the only common denominator there for years was basically X11. I have heard exactly no one ever ask, oh when is that app going to be available for KDE or GNOME. For example, to take something recent here, do the people writing the Zed editor promise a particular DE support - no it's available for "Linux."
As to earlier mentioning distros - for a GUI app, there’s more pain from intra-distro variation than inter-distro, both across configurations and supported versions.
Now the big thing, the even bigger thing is probably native Wayland vs X11, but no one says, oh vendor will you please bring your app to KDE or GNOME, specifically. 99% of the time you are happy if you get anything at all.
So the concept of native on Linux (Desktop Linux) just isn't something usually worth discussing.
Linux is not something that encompasses a GUI, so this is a misguided way to frame the underlying concern. One might as well ask what toolkit is native on smartphones, or what language is natively spoken by humans.
We should instead ask what is native on Plasma, or on GNOME.
"Oh, bother. That would mean I have to think of four things instead of three."
Well, yes, Pooh. But the things that make them different are the things that make them, them.
"Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea."
The stupid idea is thinking that building native UIs is targeting a clean, non-moving target and implying it is not astronomically harder than doing something cross platform that is between mediocre and good enough for everybody.
Whenever someone says “just do native” it always turns out they have a cockamamie definition of native, otherwise they would realize the gravity and general unreasonableness of what they were asking.
On a side note, what’s a major* reasonably complex app that isn’t a music player or an IRC client, or something with a simple shell around a canvas like a browser, that targets both Plasma and GNOME natively.
* And whether anyone likes it or not, few people care (as revealed by $$, not bitching on a forum). Blame electron, the web, but even Microsoft cannot even define and maintain a native LnF for their core operating system. As I alluded to, the only small community that cares are those on MacOS and iOS, where there is a HIG that more than 2 people have read and give a shit about, and there is a small market of people that value well integrated Mac apps that will actually spend money.
Targeting Win USER32 +/- XAML, Qt, GTK, and AppKit is costly and thankless when you probably could have just used Qt, JavaFX, or Flutter, etc.
So that means one has to target both GTK and Qt to be native on Linux. Fat chance of that on anything but yet another music player or other relatively trivial UI app.
In any event, that still doesn't answer what it means to be "native"? And my point is I think most definitions are dumb or useless.
If I'm running a GTK desktop, Qt apps are generally not "native" no matter how much theme fuckery one tries. Native can also speak to other common UI affordances and design guidelines, and there sure as hell is nothing like there is in the MacOS world for linux. Some core GNOME and KDE desktop apps maybe, but overall there isn't much adopted standardization in Linux world.
90% of the work I get done involving a GUI outside a browser on Linux usually involves Java, whether it be Intellij, ghidra, etc. Maybe I'll pick up blender from time to time. Audacity, there's a good one, targeting (for now) a cross-platform toolkit that pretends you can have your cake and eat it too - wxWidgets never fooled anyone - they sure as hell don't look native on MacOS, and they invariably look much closer to what they riffed off of, a 90s MFC app. (And wxWidgets wraps GTK and AppKit, so is it native? If so, native is meaningless IMHO. If not, why not?)
> So that means one has to target both GTK and Qt to be native on Linux.
Doesn't it mean that you can target _either_ and be considered native?
Also, I'm not sure I buy the claim that of "GTK and Qt are native" in the first place. I'd say either that there is no native UI, or if I must call something native, it's the toolkit the desktop environment uses. And yes, that does mean that there is no "Linux nativeness" like there is Windows nativeness, as every DE is different. And rightly so, because one could in principle write a different DE over the Windows kernel, whose UI would behave differently.
> Doesn't it mean that you can target _either_ and be considered native?
Well, no because I was agreeing with you, if you're going to grudgingly accept your definition for native, the toolkit the desktop environment uses, that means you would have to target both Qt and GTK unless you want to draw a line in the sand and say fuck it to one of GNOME or KDE as assume they don't exist. Sorry GNUStep. And this is nothing to say of GTK 2-4.
I agree that just saying GTK or Qt are native in a vacuum outside of DE is a completely useless definition, and even taking DE into account is a tenuous one.
As for Windows, what GUI toolkit does the desktop environment there use? That's a trick question.
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.
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.
> Both Qt and GTK have facilities for integrating into each other’s desktop environments
Neither Qt nor GTK are desktop environments and Qt certainly isn’t defined by a dominant desktop environment - KDE isn’t even what pays their bills.
You’re still proving my point. The common denominator here (on Linux) is just X11/Wayland. If it works out “pretty okay”, then score one for a cross platform toolkit. Still no idea what über alles “native” means.
Let’s go back to the original comment I responded to… why should I not just continue with the Qt “stupid” “hobbyhorse”
You missed the sarcasm. If all can exist together, which one is the “native” one? If the answer is all of the above, then the consistency argument for native doesn’t hold much water.
Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?
Yeah I do see why they don't want to do it and I see it as a critical failure of risk management.
If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs.
The risk analysis of building against supposed cross platform "solutions" just doesn't work out. Why do we keep trying to do it?
The idea of cross platform UI is frankly "f*cked from the jump" and should never have been a goal. I think it's only a goal because it's intellectually satisfying, not because it's really desirable.
Cool, none of that is remotely relevant to what we are talking about here.
Your anecdotes are dated and you should think about updating them so you don’t talk so confidently on things you don’t actually seem to know much about.
I mean that sincerely not as some internet gotcha there’s just no need to sit there defending a position that is based on old info just for the sake of it.
As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.
It's really something I know nothing about so I googled WinUI3 and the 3 first results are microsoft website and github, and the next two are "is winui3 dead ?" and "Oh winui3 is really" dead. So it doesn't inspire confidence :)
I suppose it was incorrect of me to say it hasn't "officially" launched then. But one would certainly seem to get that impression, considering it's missing major features (data table support?) isn't anywhere near feature parity with either WPF or winforms, and doesn't even have a visual editor (which should be table stakes for a modern 1.0 release from a company as large as Microsoft).
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
Electron-based apps are also everywhere and they are through and through bad and a step backward. I would take caution to not do appeals to authority. I would extend this assertion over any javascript-on-a-webview-based GUI framework. Awful concept from start to finish.
The fact that you failed to give any specifics to support your superlatives leads to suspect that the comparison with Electron is well suited.
Not OP, but what makes Flutter good IMO is drawing directly to native canvas, a very good hot reload implementation and AOT compilation.
There are three ways cross-platform UI frameworks draw UI. 1) wrap platform controls, 2) use webview or 3) use low-level graphics API.
Option 1 has to design controls to cater for the lowest common denominator. And there is a higher chance that an OS update might break things that in options 2 or 3. Being based on wildly different APIs (for each platform) increases complexity of creating and maintaining custom controls.
Option 2 has to render UI through a high-level declarative language made for documents.
Option 3 uses same APIs as native UI frameworks use. It's basically alternative implementation of an UI framework. Downside is that it has it's own look and feel, which is mostly an issue, if native UI framework is more polished.
Flutter, being option 3, is more similar to a game engine, than to Electron. Low-level graphic APIs maintain good backwards compatibility, so OS updates don't affect the framework much. Less maintenance is needed.
Good hot reload makes use of XML unnecessary and allows to declare UI in an actual, more powerful programming language. Overall, this removes another layer of complexity. (MS take a hint)
AOT compilation enables fast startup times and less pauses. Which is good as end users are opening and closing applications all the time.
You are right, sheer popularity is not the argument for the quality of the framework. I wrote those two sentences separately for different purposes (the second was more of a reflection of other comments in the thread. I should've put it in a separate paragraph or elaborated more.
I recently started Immich and also say the awful lag. But apparently this is due to a slow "album sync" running often on the main thread. Not the fault of flutter.
I don't know how syncing my 200 albums can be that slow but they are a big project to move it off of the main thread.
I'm suspicious of those because it shows an ebay logo but then shows an app I've never heard of or used...is this the same for all the other logos? Where does NYT use flutter?
I recognize that as the NYT Games (formerly NYT Crossword) app.
It has some very annoying non-native behavior, like bringing up the text selection/highlight menu in inappropriate places (in a word puzzle with no selectable text).
Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do.
Shepherding these patches is no fun when you have your own changes to work on that are more important to the team.
We did something similar, by creating an external fork where changes could be tried out by the community, without necessarily being accepted into the internal version.
I think a fork could work if there was enough external momentum, but even 20 people working full time would actually be pretty good for an open source project. How many developers will this fork attract? The fork would need to attract other businesses who can put people on it.
One downside is that the code isn't tested against google3. Sometimes you find actual bugs that way.
Edit: reading more closely, the complaint doesn't seem to be that patches weren't reviewed, but rather that bug reports weren't investigated. That's definitely something outside developers could do more of, and seems a lot easier than forking?
The main Flutter GitHub repo does have infrastructure to run PR against all Google internal tests (which as you say, does find real bugs). https://imgur.com/a/Ih2oQIS
Does that automatically run against every PR? What mitigations did you have to put in place for Google security to allow running untrusted code from PRs on internal CI?
Here is a paper describing google3 https://research.google/pubs/why-google-stores-billions-of-l..., which includes the policy that “To prevent dependency conflicts, as outlined earlier, it is important that only one version of an open source project be available at any given time.” More documentation on The One Version Rule for third_party: https://opensource.google/documentation/reference/thirdparty.... This rule may make it more difficult to upgrade a third_party library frequently since the maintainer of the third_party library has to test all the uses of the library from all teams, rather than each team deciding when to upgrade.
I used to maintain the internal (single) version of numpy and scipy and honestly I think the one-version rule was awesome. It greatly reduced noise and churn. It meant far less breakage, and it was easy to find and fix all the breaking tests when I was updating to a new version. I guess the only downside is sometimes an older version of numpy would prevent deepmind from making some sort of ML advance until I upgraded to get some new feature they wanted.
Couldn't flutter work as public-first that then gets vendored into third_party?
Or is that literally the fork strategy you are talking about that I'm too dense to understand?
Or maybe it’s not important to the community either? Sometimes, a bug is pretty obscure and only important to the person who filed it. People will get annoyed if they aren’t investigated, though.
It’s good to be a little skeptical when people claim to speak for the community just because they’re part of the community. Often it’s not so.
Yeah, this seems to be a common theme with Google's open source projects. Bazel feels very similar in many points.
It obviously wouldn't exist if not for Google putting resources towards it, but Google's (and google3's needs) are so significantly prioritized that it hurts the community. E.g. due to the low allocation of resources and extensive usage of rules_proto and bazel-skylib inside google3, they are completely ossified and the community has given up contributing to them and instead created either forks or contribution-friendly wrappers.
i avoid contributing to flutter because it feels like a google soon to be abandoned project.
hacks like not accepting tabs in any tools and using space indentation wrong on top of it. tools ignore parameters like port numbers just so it works better for Android studio very specific use case while bringing pain to any ci pipeline, etc.
> 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. I've certainly worked on things with much worse ratios than that.
> one has to critically assess why a team that loves external contributions has only managed to merge contributions from 1,500 developers over a span of nearly a decade.
External contributions from 1500 developers over a decade is a lot. That is an unusually high number, not a low one, and backs up Flutter's claim to love external contributions.
The fact that this person thinks that they can just magically conjure up dozens of volunteer PR reviewers is wild. Everything about this post makes it pretty clear that they don't have the slightest clue of the scope of what they're trying to do. This feels like one of the standard examples of an ex-bigco person setting off on their own with no understanding how just how much the bigco did in the background to facilitate their job.
Our user base is of a similar order of magnitude, with around 70 developers. It doesn’t seem like a large number, indeed! A small minority frequently contacts support, suggests features, etc., while the majority simply uses the product.
50 people is a pretty huge team at Google to start with, there’s teams of <5 that support weird bits of core infrastructure that serve billions of users an hour.
I believe it. I've never worked at Google, but I was the engineer for SMS/Voice registration at WhatsApp, ocassionally with one other engineer (I believe the team was 3 when I left, not sure if it grew); I think there were two engineers doing my job for Facebook; although they had a little bit more scope, since there were more kinds of SMS they sent. That doesn't have a huge request rate, but it is super important.
Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.
Exactly, there’s really like three dozen or so people globally who really should never be in the same room at the same time as the risk is too great they get hit by the same asteroid.
I’d put “person who makes sure WhatsApp verification codes work” on that list.
> I’d put “person who makes sure WhatsApp verification codes work” on that list.
Thanks! That part of my job really wasn't too hard though, once I got things in order; but it was the easiest part of my job to describe. Just a lot of debugging from sparse data, and trying to get things to work a smidge better, because smidges here and there add up. It really helped to have a great customer service team that bubbled up usable information from users.
Debugging things from sparse data gets you involved in a lot of different systems though... That and I told people I worked at an ISP in the before times, so guess who got to fight with sendmail, and guess who got to own our Domain accounts and DNS accounts and guess who got to get x.509 certificates, and who had to fight with Google Apps to make mandatory 2fa usable, etc. Basically everything without a person and server adjacent got me. :P
Anyway, I've moved on (replaced by a team of three on the SMS stuff amyway, much better bus factor) and am semi-retired and no longer in any critical path, which is a lot less stress.
World population is 8.2 billion. Assume that 1/3 are asleep at any given time, leaving 5.5 billion awake. It’s not a huge stretch to imagine 20% of them (1.1 billion) using core Google services during peak times.
I don't find it hard to believe. I am not at Google but I work on a product with 200 million MAU, in a core team that serves requests to every single one of those users and there are 6 of us.
Push notifications need to connect to that many devices every hour easily
You may not get a notification every hour, but the phone still have to connect to Google APIs to check to know that.
You can say same thing about say location services, every phone if powered and connected to the internet would ping more than one an hour, more than billion devices are definitely online at any give time, not just Android phones, also every android TV, tablet, watch, and the hundreds if not thousands of other devices running GMS on top of AOSP .
There are probably few other APIs in GMS that would ping at least once an hour each device that is powered on, perhaps things like NTP for timing alerts or Emergency Alerts etc.
You may consider them "Background Services" , most of them however have some foreground UI if they need to, and users will notice if they don't work
There are roughly 5 billion smartphone users now, those devices are almost always on and sending background data somewhere. By volume, more of that data guess to Google than anybody else, on the order of hundreds of network requests per device, per hour.
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.
Absolutely, yes! Then make it two or three people, maybe 10 and there are still n-times too many people working on flutter compared to cURL.
Which boils down to: Number of devs vs. people using something is a very bad metric. Even number of supported devices won't work good in this case (I assume cURL runs basically everywhere).
I think it's very difficult to estimate complexity, and then make a statement about "how many people are enough" is even more difficult. Some environments are harder and more complex, some are just very heterogen and some are both. Sometimes it's the organizational overhead, maybe even something else.
How is it bizarre to compare the impact of a low number of engineers affecting millions of people. In the case of WhatsApp it was 35 engineers affecting 350 million people.
The support needs of developers is generally higher than those of a messaging user. How often have you had to contact the support of a messaging app you use? Now think about how often you create a Github issue or PR for an open source repo.
WhatsApp has a very narrow use case and feature set to support. Flutter is a multi-platform framework for developing apps like WhatsApp. It seems like a apples and oranges here.
What about Python? They had 34 core developers in 2017 [0]. Python is used by millions of devs. They have to support a multitude of platforms as well.
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
to be fair, Python's performance has lagged far behind comparable languages (e.g. JS) for at least a decade. maybe more devs could give it the V8 treatment?
I’m not sure what you mean by this but Python can be very performant when you want it to be. That is to say, when you build computation heavy parts in C (or Zig), and remember to avoid the various performance pitfalls like not using generators when you didn’t want to load all those millions of elements into your memory.
What sets professional Python aside from most other programming languages is that everyone who uses it knows that it’s terrible and how to deal with that. Which will sometimes be replacing parts (or all) or it.
To say that it’s inherently less performant than JS is frankly silly though.
CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector. CPython is way, way simpler than V8, but it's consequently slower. It's just the consequence of Google putting centuries of developer-years into an engine.
You can't just claim Python is fast because Python's C libraries are fast. Those libraries are fast despite Python. Torch is extremely fast, but it's fast from C and Lua too. There's valid reasons to want to compute in your programming language. Python is, ironically, probably popular because its slow speed encouraged users to write blazing fast C libraries rather than even try writing native Python, vs. settling for middling performance as in Java or .NET.
I shouldn't have to get out my hammer and tongs when NumPy doesn't implement the operator I need. Why can't Python be fast like Julia?
Yes. Is that so weird? JS is also performant when you don’t use JS considering you’re running it on C or Rust and are likely using the FFI if you’re doing any form of computation heavy work.
Yes, it's very weird. When I write JavaScript, I expect it to run reasonably fast because of the JIT - and it does. I've never felt the need to use FFI, and libraries that use it generally do so because they want to interact with pre-existing C or C++ code, not because it's the only way to get decent performance.
Flappy Bird was taken off the store by its author, if you take WhatsApp off the app store, that would be a completely different reaction to Flappy Bird.
The whole point of running an opensource OS/vm/runtime/etc is that you can tweak things here and there when you need them.
Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.
Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.
We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.
Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.
Process groups, some solid performance tweaks to ETS and Mnesia, etc. It all got upstreamed or became redundant eventually. Rick Reed gave a couple talks about it around a decade ago if you can track down recordings.
I mean we do actually have many years of real life experience at this point of how they perform in the real world.
I’ve never actually come across a better maintained project personally. It is incredibly thoughtfully developed with a high level of attention to detail who have successfully shipped a huge number of major improvements in ways that made sense.
There is a premise in the post that implies Flutter is poorly maintained and that’s just not a commonly held belief by the community at all.
As I hinted to in another comment the particular person behind this is a bit of an oddball and I think there may be other reasons that drove this decision in the first place in addition to the ones he gave in the post which for the record I’m sure there are some things he wishes were prioritised differently but this fork seems kind of very “him” rather than a popular position that people were begging for.
these are also 50 google devs (that may or may not be at the company anymore) by this estimate. They could have just said there were critical tickets not addressed by Gooogle and their PR's ignored, and would have gotten a much more sympathetic response.
Yeah, the person primarily behind this is a bit of an oddball in my experience who had a somewhat contentious relationship with the team which he himself was once a part of and it’s not clear if he left or was asked to leave.
But reading that post I couldn’t help but shake the feeling that there might be other non disclosed reasons for the fork because some of the ones he did give as you pointed out didn’t make a lot of sense to me either.
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.
You’re most likely confusing Flutter with the Python team which was laid off but the work moved to a team in Germany. The Flutter team has not been laid off to my knowledge.
We got around 3m with seven guys, so yeah, and we don't even have on-call rotation / schedule, even though emergencies do happen from time to time. They think 1:1000 ratio is too big as well? That's crazy.
Are you comparing a developer platform to consumer software there? Dev platforms have radically different support costs to regular SaaS or mobile apps. Developers are really support intense.
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?
No, generally developers prefer to request help or work around an issue than dive in and fix it. The activation energy for contributing to an upstream project is high and very few do it.
Developers are support intense because dev tools and platforms get used in a bazillion ways and combinations you can't predict. It's not like a nice consumer app where the user can only press a limited combination of buttons, and test coverage can be quite exhaustive. GUI toolkits are especially a bottomless pit of edge cases and bugs because they have tens of thousands of API methods, enormous numbers of features, they can all be used in combination, they have to run on multiple platforms usually and those platforms also have bugs etc. The support costs of a GUI toolkit are basically unbounded.
no, if I'm using your platform, it's because I really don't want to deal with the stinking pile of abstraction below that. so on the contrary, I would see it as a negative if the abstraction was that leaky.
As someone reliant on Flutter, it is likely better to rip off the band-aid now than wait for a slow, prolonged decline. That being said, whilst I am at least somewhat comforted that the person taking charge is someone who was involved with the Flutter team at Google in the past, rather than a random, overenthusiastic person, I have a few crucial criticisms on this post that make me skeptical.
For one, I'd recommend adding a newsletter field to the website/blog, simply so those who may not want to test or participate right away can stay in the loop. More importantly though, the two links asking for reviewers and leads just link to a private Eggs account, which, even before someone decided it was a good idea to just make content appear in an unsorted manner (random post from 2023, then 2021, then 2024, then 2020, ...), has never been an ideal approach for such projects in my opinion. I honestly thought I had clicked on the wrong links when two eggs profiles appeared in new tabs.
Forcing potential devs to create a third-party account on a social media site, then send in DMs is likely not the best way to get such a major project of the ground and having public repos or at least a contact form set up would go a long way, especially since that also makes it easier to enforce some ruleset for applications.
Additionally, consider listing what changes have been implemented in Flock at this stage. As it stands, it appears impossible to easily tell what one can expect without diving into the changes [0] one-by-one.
Still, wishing you the best as Flutters development and approach to both what goes into which branch, as well as keeping up-to-date with UI elements in target OSs has been leaving a lot to be desired to say the least. I still feel that, despite all shortcomings, for certain applications and workflows, Flutter/Dart remains the best, and it would be a shame to see it unmaintained.
No Eric founded Flutter at Google. However, Google had previously acquired another company called Flutter, and they had that domain lying around, and decided to use it. That's what I understood, at least.
Guess you're right. Establishing a "Flutter org" counts. Though, I've never seen folks in this space (Bjarne Stroustrup or Anders Heljsberg for example) say they're the "Founder" of XYZ language / framework.
I've nothing to add to the conversation, but I jump on this oportinity to tell you that i like the content you've made with Adam Barth on yt very much, have a great day :)
It's not Flutter by own admission, it's very likely not backed by a foundation, and I highly doubt that Google consented to its "Flutter" trademark used for such a foundation.
> 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.
Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It's getting a bit long in the tooth, but I feel like 'the mythical man month' should still be required reading for software devs. More devs != better.
> Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It depends on an org's priorities and what gets put on someone's reviews.
During one of the years when I worked on Windows Mobile (before Windows Phone!) we had an objective handed down from on high that we were to spend so many hours a week on customer support forums helping people out.
Well, for that year, customers all around the web got great support right from engineers! I got to paste lots of positive feedback from end users in to my yearly review, and I felt great about it!
If Google cared about supporting Flutter as an Open Source project, they'd make the health of the open source project one of the measurements going into employee reviews at the end of the year.
Totally– This was in the early days of open source .net, when it was still called .net core. We had just moved onto GitHub and I don’t think microsoft had quite figured out how to manage that organizationally. There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
Historically when MS was filled with software nerds, the fastest way was to post on an online forum!
Sadly those days seem long gone. It doesn't feel like Microsoft empowers employees to really reach out and help customers anymore.
I do remember responding to those Tier One support contract requests. IMHO that was a better system than what the large tech companies do now, which is basically just ignore customers no matter what.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.
———-
Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.
That ethos runs through everything the WA team does. I learned a bit about it when I was at fb and I was beyond impressed by how few servers WA used for its core infrastructure. It's a really well engineered product.
That's still plenty of people if you got a few thousand people at AWS/Azure or in this case Meta's in-house cloud making sure your service is running and scaling as it should.
Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet.
Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
> Once the project already exists, is largely feature-complete
That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative.
> mostly in the "fixing bugs and small annoyances" phase
I don't know of any UI framework that has had the luxury of ever reaching that phase.
> then Linus's Law [1] takes over.
If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/
This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone.
> if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done".
Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.
I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs.
It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.
Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.
The OP was talking about developers serving the needs of developers, and the ratio involved there. This is different than developers serving the needs of machines (fifty developers to some arbitrary number of machines is not automatically impressive) or developers serving the need of users. One would expect the ratios involved to be different for all three and highly context-specific.
I'm confused .. is this a Google-led fork? Is "Flutter Foundation" a google sponsored foundation? If not, why use "Flutter" trademark? Also, if the fork is called "Flock", why is this called a "Flutter Foundation"?
They kind of did it before with DartAngular. Maybe this is a Red Hat/CentOS division, where Flock is an upstream community edition and Flutter is ... I don't know.
I asked because it is confusing. My assumption would be that if this is an independent organization they couldn't use 'Flutter' because that is a registered trademark of Google, and they would say they are not connected to Google. I'm looking through their website and github repo for any statement that either asserts or denies a connection to Google - and I'm not seeing it.
When I led the Google team we had pretty good analytics. `flutter` was for a long time opt-out with analytics and would phone home to Google and report usage. We filtered out docker containers and things that looked like CI and saw usage near 1M monthly actives when I left Google a couple years ago. I'm sure it's up since then.
There are 10s of millions of web developers in the world. Doesn't shock me that Flutter could be over 1M monthly (and probably several million annually).
There are just a lot of apps and app devs out there.
That said, I literally only use Flutter as a hobbyist.
I made a basic web game for a friend, and a small web app that helps me manage my music lyric videos. I ultimately picked Flutter because I find it easier than actually building websites.
Dart is amazing.
But I'm not deploying to millions of users. At most 10 people have seen my Flutter apps.
It's VERY good for creating quick crud apps with Firebase.
Just counting the number of us who have it installed and might of spun up hello world says nothing about it's actual market share.
To be clear, I absolutely love Flutter, but it's still not something I really see job listings for.
on behalf of one of the Flutter founders, thank you for the thank yous.
I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
> I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker?
No, I sarcastically thanked him for free-association about the # of job listings he sees for job listings he's not looking for and what that means about the language.
I'm guess I'm capable of being curious and engaging in conversation, beyond sitting in the bleachers grading everyone on my scale that at 100% is "koolaid drinker.", depending on if I feel like the things they're talking about are on Team A or Team B I've identified.
Then again, that perspective would sort of come naturally if I were reading hysterics into every comment I read. "Big fuck you" is textbook catastrophizing.
My point was you just can't count SDK downloads as developers. Is every CI/CD pipeline a developer ? The founder of Flutter who posted that stat has a startup which is heavily invested in the perception of Flutter being popular.
In the Unity community we aren't afraid to critique Unity and even suggest trying other engines. Of course Unity isn't open source so you don't get articles like this where someone claims it's time to fork.
At the same time, Unity uses C#, so you can take your skills, and even some nuget packages( with a bit of work) elsewhere if you want to switch.
Flutter requires a higher time commitment since I have to learn a language that's exclusive to Flutter. If this ship goes down I can't use Dart with anything else.
Anyway, I think job postings are a much better metric of adoption. I like Flutter, I've used it for 4 years and I want it to succeed. I don't want to go back to react native!
If you think its not popular until that increases past one of: JS, Python, Java, C#, PHP, C/C++, Ruby, Go, or SQL...I don't really know what to say. :)
Flutter in Kotlin instead of Dart would have killed! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).
Just seems like personal preferences. I've used languages with extensive pattern matching and don't feel like I'm missing out without them. Don't really see the problem with Gradle or Static Delegation either.
Then you won’t understand what made Flutter “click”. I work with Kotlin, Gradle and Compose on a day to day job and it is absolutely dreadful experience. Sure, it beats working with Java… Java 8.
Yes, I agree, trying to use Kotlin instead of Dart would have killed Flutter.
I've been hearing about Kotlin multiplatform just as long as flutter, and writing Kotlin since 2019.
Kotlin is a horrible daily driver.
I worked on Android for Google at 7 years, and maybe it'd have a better chance if it didn't win internally. As it stands, there's too many organizational boundaries created, and each organization holds itself accountable only within itself, so it's sort of the worst of all worlds, impedance mismatches everywhere, and nobodys fault they exist
I'm always stunned to read wish casting about Kotlin because there's ~0 path to even basic things that change productivity dramatically, like hot reload.
> I don't hate Kotlin, it feels like Google's answer to Swift
You have the wrong order: JetBrains created Kotlin[1], and anything Google had to do with it was just adopting their language. Same story for Gradle choosing it over Groovy
> Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development?
Google doesn’t promote anything. There are two competing teams with their own agendas. Flutter’s bills are mostly paid by internal usage, as far as I know. Android is mainly focused on Android part of Compose.
Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
> Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev.
Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
>I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
I'm not exactly senior to senior, but I hopped from mid level hobbyist Unity dev to professional Unity dev , to mid level .net dev. I have a very specific niche though.
I'm very comfortable with my career.
>Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
Android Studio is free ? Are they really making that much money off users using Kotlin outside of Android Studio ?
Android Studio is subsidized by Google and works pretty much only Android. The moment you have to work something more, e.g. some Web stuff you need to pay for IntelliJ Ultimate as it’s only IDE that supports Kotlin.
They even have Ktor (Kotlin web framework) plugin available only in Ultimate. For any non-trivial Kotlin development you need to have Ultimate.
Only for the crowd, I need point out that no one's arguing there's more Dart jobs than C#.
Re: multiple frameworks, I worked at Google and would argue I know as much as anyone does exactly what happened there, so I can't agree it's weird, per se. Handwaving, I'd say that's because the situation seems more 'certain' or 'settled' to me, for good reasons, but ones not worth getting into.
There's absolutely tons of threads to unpack in your comment, I wish we were in person.
Speaking generally, based on observation you gravitated most towards discussing qualities of a job one might or might not get:
I essentially left my job at Google for no paycheck, partially because Google x Koyaanisqatsi, partially because I just couldn't imagine having to go back to write Kotlin and/or Java day to day and being criticized either way. That being said, it's deflating seeing Flutter job listings after getting into this whole industry from iOS dev. Thing with Flutter jobs is there's tons of low priced job seeking competition that are smart as hell.
That's because it is unusually effective in environments where people can't afford a Macbook only for iOS dev, and at this point in its lifecycle, it self selects for people who get experience with new frameworks
(On a serious note), inside Google you tend to get more easily promoted if you launch new products than if you maintain existing products, so it could be tempting for the employees themselves to follow in that direction.
yeah, it fascinates me - both Apple and Google started these new UI framework things after Flutter, and both didn't land it, but instead, landed some half-baked thing where individual components can render live in the IDE.
That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resize the window to imitate different screen sizes!", not, oh there's a bug, fix, save, insta-reload, verified fix. No holistic screens, or loading info from a database, or mutating data.
I assume this is an extremely hard problem. I remember trying to get Obj-C hot reload working 15 years ago and it kinda half-worked some of the time. And its not like I can edit the C++ my Flutter app is linking against and get instareload.
But still, it's one of the things thats easy to point out and drives home that these once-a-decade-or-two frameworks started in response to React Native/Flutter aren't addressing the fundamentals of what made them a sea change. Industry is risk averse and we make too many decisions similar to staying on track to launch MacOS 9.110 in 2024, instead of biting the bullet to get OS X done.
> both Apple and Google started these new UI framework things after Flutter, and both didn't land it
For Flutter to have fully landed it, it would take more than just hot reload. I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?
Yeah hot reload's just a one-off example that I think is the simplest way to relate the experience of SwiftUI vs. Compose vs. Flutter, though, the first two are long in the rear view mirror, I've been Flutter only for about a year.
Good question -- I don't think its the wrong question? Maybe? :P Tough to phrase on my end too.
I only feel native speaking in iOS or Flutter, even with the Android experience, forgive me: I guess I'd summarize it as "yeah, you're right. if you're wondering if they're ex. calling CoreGraphics on iOS, no" (well, they do, but for text rendering. Not for a red rectangle)
Generally, Flutter Web is rendering into a WebGL surface using Skia -> WASM (2.2 MB download! modern miracle). macOS, iOS, (done) Android (soon) are switching from Skia to Impeller. I think the thrust of your question is "are they still bundling the render engine?" and the answer is yes.
I find the way you phrased it intriguing, in that, before reading your post I'd say drawing to a Skia canvas is as native as you can get. But I realize now that means I was overindexing on "close to the metal", and its apex not-native to say "gimme the framebuffer and i'll take it from there"
I'm a bit picky with design stuff and I loooooove that Skia's bundled and I can rely on it cross platform
https://flutter.dev/showcase has a few examples. Flutter is everywhere at this point. TikTok in China (Douyin), PUBG Mobile, MGM Resorts, eBay Motors, Kijiji.com, Grab are a few off the top of my head. And of course a whole bunch of Google apps (GPay, Earth, Classroom, etc.), Toyota cars, LG TVs, Google's own hardware devices, etc. Tonal is probably the app I used most often that's Flutter. Caribou Coffee, Betterment, Norwegian Cruise Lines, NuBank, Realtor.com are other random apps I've used that are Flutter.
Do you have a source for that claim? I'm pretty sure that is incorrect. Bytedance has said they use Flutter but for other projects.[0] Douyin is not mentioned anywhere.
I don't have access to any devices with Douyin on it, so I cannot confirm current usage.
My knowledge of their usage is from discussions with ByteDance some many years ago when I was in charge of the Flutter project at Google. At the time they were using Flutter in 50+ applications (probably most of them internal), including Douyin (TikTok for China) as well as physical hardware kiosks on their campus, web apps, etc.
I just tested Douyin 23.5 from 2022[0] and it does not have the two finger scroll bug.[1] It is of course possible they were carrying their own patch for it all this time but that seems unlikely. I doubt they are using Flutter or if they did it must have been a long time ago.
[1] https://github.com/flutter/flutter/issues/11884 - click on the search button in Douyin on the main page and search for something to get to a regular ScrollView. You don't need an account for this.
I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
I refuse to sideload arbitrary APKs, especially from bytedance. I feel bad because that is irrational, you did, and it'd be really helpful if I did and just did this myself, but, you should install FlutterShark and check: https://play.google.com/store/apps/details?id=com.fluttersha...
Why is "bug" in scare quotes here? It was most definitely a bug.
>I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
The actual fix was pretty involved. I doubt a large company like Bytedance would want to carry around extra patches at the gesture level that make the dev cycle more difficult. Having one person carry a patch on their local machine is a different story.
Anyway, the Bytedance blogpost says only 200 devs are using Flutter which would make no sense if it was used in Douyin, and LibChecker[0] returns no results for libflutter.so.
> Why is "bug" in scare quotes here? It was most definitely a bug.
Is it? I thought it was cool, I can't think of why its disruptive to scroll a list faster if you scroll with more fingers.
> I doubt a large company like Bytedance would want to carry around extra patches at the gesture level
I'm a solo endeavour, and I spent ~30 minutes to do exactly this (patch gesture behavior) two days ago. I was stunned how easy it is. But I grew up on versioned closed source dependencies on Apple iOS frameworks that you had to patch the runtime at runtime to fix, so I'm easily wowed.
> 200 devs are using Flutter which would make no sense if it was used in Douyin
Seems reductive: "Only" 200 fulltime, 800 in the company...and we're in a discussion about how 50 maintain _the entire framework_. :)
If you have an Android phone, get FlutterShark and check which of your installed apps use Flutter. It's a surprising amount actually. For example, I just recently discovered that Supercell uses Flutter for their Supercell-ID flow.
It was 8 out of 86 apps for me (9% of my apps). Including Hacki, the HN client. It's a good variety of apps too, from big billion dollar companies to tiny games I downloaded from F-Droid.
Since the beginning of Android apps could see what other apps were installed on your phone without asking for special permission.
They finally added a permission for it - QUERY_ALL_PACKAGES - in Android 11 (2020). Unfortunately it's one of those stupid permissions like filesystem access where you have to apply for it via a form, and only whitelisted use cases are allowed:
> Permitted uses involve apps that must discover any and all installed apps on the device, for awareness or interoperability purposes may have eligibility for the permission. Permitted uses include device search, antivirus apps, file managers and browsers.
I suppose that situation is slightly better than "anyone can do it for any reason".
If there would be 1M flutter devs per year and on average team had 10 devs (rather rare most mobile teams would be smaller except really big apps) and development of app would take ~1 year you would expect minimum 100k new flutter apps in app store every year. That seems highly unlikely.
I suspect there's a lot of larger apps out there which use Flutter for one feature or set of screens but the majority of the app isn't written in Flutter. You could have a team of 100 working on a app where only three of them actually touch flutter on a regular basis, but depending on how exactly you capture analytics all 100 of them may get counted.
I‘ve worked for over a year, almost full time, on an internal Flutter app that never saw the light of day (maybe later, if the stars align). Many apps just get their support section revamped with Flutter because there’s no need for that to look fancy; but they‘ll still count against that quota. Many devs prototype their side projects with Flutter, but never release them. Etc
I'm pretty sure many/most professional app developers are in long-term projects, working on the same app(s) year after year. So for those devs the app count never goes up. That's at least my experience -- development work only stops when the app is pulled off the stores for business reasons.
Yes. Realistically off by at least a magnitude. There is literally zero chance there's 1 million active developers working on this experimental Google Tech out there.
while I'd agree with you that 1 million is too high, Flutter certainly is not experimental Google tech. It's widely used in particular internationally. I talked to a ByteDance guy two or three years ago and I think they alone had about 1k Flutter engineers. Nubank, Alibaba, BMW, Ebay use it extensively.
Flawed metric but eyeballing VScode Extension installs, Python 140m, c# 30 mil, Go 15 mil, Flutter 10 mil. It is very, very popular.
Just looked via google, and while no one really knows, common estimates of the number of web developers seem higher than that, on the order of 27 million.
Your point may still be valid, but... is 3-5% really that high?
(No dog in this, I'm not doing web development at the moment, although I have and probably will again.)
It's possible that they also count students and amateurs such as me, who only used it in a small project never published. There could be a million I guess, but professional developers are probably a lot less.
I think this is a strong possibility. For example, I don't work in programing and don't intend to ever work in the field. I do it as a hobby. I downloaded flutter, played around with it for a few weekends and decided it wasn't for me. If you go solely by number of downloads I would be counted as a 'flutter developer'
There's 200k weekly downloads of node on npm. A million flutter devs means that there's a comparable amount of node devs to flutter. I'm not sure how else to estimate it, but there's 170k github stars of flutter compared to 100k node, and a roughly equal amount of forks.
Github shows 98% of code is "Shell" on top of that there are also many different package managers that people use: fnm, volta that are build with rust. You can also install nodejs using homebrew.
No. It downloads binaries from nodejs.org. There is no "official" canonical means of managing Node versions. It's just a grab bag of community tools like NVM.
My experience when I last looked into Flutter was that it was heavily used in India - at least based on who participates in the community online - and much less elsewhere. That's not a value judgement, just might be a factor in why you don't hear much about it if you're not in India.
they're just too close to the problem and overestimating their relevance.
just because someone cloned a repo once or an NPM package was downloaded doesn't mean someone is a flutter dev. I don't know what the best metric would be, but its relevance is definitely overstated
Yeah, people like to count their "downloads" and call that their "users", but it's at least an order of magnitude difference in my experience. Sometimes a 100x difference.
I don’t sub him on YouTube - but I’m not lying when I say everyone I know IRL who does sub his channel has worked as a barista at some point in their lives (…and purchase actual chemical-lab supplies for their coffee brews).
Flutter is truly a piece of great tech with remarkable quality and value. I hope the right path will be found.
I think companies using it for commercial purposes (like what we're doing) should contribute something to the effort to help make sure Flutter not only survives, but flourishes.
Bug bounties, supporting individual developers, supporting efforts and initiatives, professional services, or any other way that helps the project move forward will be great.
> Most of our apps use React. When we first adopted React, we were pleased with the development productivity it provided, but sadly its initial performance was subpar in terms of start-up time, memory consumption, and responsiveness. After significant and complicated optimizations we reached performance benchmarks that were good enough, and yet we desired a new technology that was both fast and simple.
> To our delight, our very first prototype with Flutter easily exceeded our target benchmarks! Without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive and playful to use
> But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.
Sure, but you're compiling two radically different languages. JavaScript is dynamically typed (even with TypeScript) and Dart has a sound static type system.
It's much easier to compile Dart to efficient native code than it is JavaScript.
I wonder how it compares now with the latest version of RN that brings out a lot of performance gains induced by the removal of their native bridge, and also faster startup by making lazy loading of modules the default option
Faster and better in almost every respect we've looked at vs React Native or Electron. We're super happy with this choice we made quite some time ago.
I'm not qualified to give an in depth review/comparison, however.
Edit: we use flutter to build an app which runs on iOS, Android, macOS, Windows and Linux -- the same code base with pretty minor adaptations to desktop vs mobile and different screen sizes.
The experience has so far been fantastic. It's fast, it's relatively light weight, it's performant, it's a pleasure and we couldn't imagine doing it any other way.
We have worked with flutter since 2019; having built internal apps for our staff, public apps for our customers, small utility apps etc- this has been our experience as well. Not only flutter has been rock solid, easy and fast to develop, it has a wide array of libraries. Long may it continue.
I've been working with Flutter for a little over 2 years nonstop. Before I started this project, knowing enough react, I experimented with react native, Expo, also quasar, capacitor, nativescript, and other cross-platform mobile solutions. Flutter/Dart was just nicer to deal with than everything else. I needed to work with C code too, and Flutter made it straightforward with FFI.
The developer experience was great and the Flutter team was very responsive with questions I asked.
In India Flutter is quite popular. But I also doubt there will be professional 1M flutter devs our there. However if we include students and hobbyists, then definitely there could be a 1M Flutter devs out there.
It's probably within an order of magnitude but it's really just hobbyists, casuals and indies using it.
If you compare it to React Native there probably are more Flutter apps published but if you drill down into the top 1000 on each app store you would be lucky to find more than a few in most countries using Flutter whereas React Native definitely makes up more than 10%, maybe as high as 30% of non-game apps. I know on my phone I have zero Flutter based apps installed and almost 20% use React Native in some way.
Source: I'm an app developer so I keep an eye on these things.
I expect there will be some communication from Google at some point and the foundation will have to be renamed. It reminds me of OpenTF being renamed to OpenTofu.
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 another perpetual treadmill.
Not to mention it includes a dedicated language, which takes significant effort in its own right.
Add to that, that as a project gets larger and more complicated, it becomes harder to change and tech debt builds up.
It's not surprising to me issues are building up. I've got to wonder if a fork, while it can move forward in one respect, may just be adding more complexity in a project that already has too much.
It wouldn't surprise me if Flutter's unmanaged complexity is exponential, in which case quadrupling the number of dedicated engineers won't move the needle a lot.
> 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.
Key statement: "As Flock ships important bug fixes and features, the Flutter team can then choose to add those to Flutter, on their schedule. "
I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.
Flutter Founder here. I'm very pro open-source, and pro taking-action, so hopefully good things will come out of it. I think this particular author is mostly stirring up a bunch of noise and does not represent a significant chunk of the community, but we'll see. :shrug:
> ...the Flutter team is in maintenance mode for 3 of its 6 supported platforms. Desktop is quite possibly the greatest untapped value for Flutter, but it's now mostly stagnant.
I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.
Agree, if it pans out this way in reality of course. That'd be splendid!
NodeJS went through something similar. It was tightly controlled by a single company (Joyent) who were juggling too many balls, and progress went slowly. Community people did a fork (io.js) which shipped improvements faster, but they did so in a careful non-shitty way. This made lots of people switch to io.js, so that eventually NodeJS merged with io.js (iirc they just renamed the latest io.js "NodeJS").
I don't know of any other instances of community forks of company-controlled OSS that did something similar though. If this is just one guy who made a blog post, like a sibling comment suggests it might be, then it might not pan out this way.
The constant question of big tech OSS is who is it for/why does it exist? Did they make this because they think it's a useful tool internally, or are they trying to build a platform for external developers? If they built it because it's internally useful, then it's probably open-sourced for cultural reasons (the people working on it are used to being in open source communities and want to share what they're working on).
Unless something is specifically being made as a platform for external developers (Android and Firebase come to mind), the level of support you'll get is at the whims of the team's current product leadership and budget. Both of those things change over time - a product manager can always say "let's focus on internal developers" and put the external community in maintenance mode. Based on the article's mention of desktop support being deprioritized, this might have happened on Flutter.
Big tech funds things that would be really hard to pull off with just volunteers, but big tech projects can also be victims to the capriciousness of corporate politics and budgeting.
Also take into account inflated commits by CI bots: engine-flutter-autoroll, skia-flutter-autoroll, auto-submit[bot], fluttergithubbot, flutter-pub-roller-bot
Actions (commits) speak better than words for me - flutter managers like (kevmoo) that are responsible for PR what gonna say? Probably you not gonna hear form them "Sorry we had layoffs and unfortunately our team is to small to handle all issues for now" Same with previous google employees that are still invested in flutter ecosystems by launching commercial products around it even if not at google anymore.
This sounds bitter and misinformed. Check automotive grade Linux and check GitHub for flutter embedders. Flutter being deployed all over the place. It’s impressive. The tooling and DX is excellent.
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.
The thing I worry about is that its going to be really hard to get a large number of PR reviewers up to speed for this fork, while also maintaining reasonable quality.
I think it's going to be difficult to maintain a separate fork without diverging from Flutter, because over time, the fork will accumulate bug fixes and features that the Google version will not accept (by definition, since the proposal is to be more accepting of PRs). How are we supposed to go back to the Google version of Flutter as the fork diverges more and more from the original?
Or is the proposal that we should stick with the fork, and the fork will over time pull in the new features and PRs from the Google version? But how will that work after say 12 to 24 months of divergence? There's going to be a hodgepodge of new features and bug fixes on the fork, and then Google will release a new version of Flutter with a whole set of new capabilities ... and we'll be stuck having to choose. Or we'll have to do a really hairy merge between the Fork and the new version from Google.
This just seems scary to me. Especially since for any given team, there's usually one ... or maybe two things we want to patch into the Flutter tree. Its easier for us to just apply those fixes onto a new version of Google's flutter tree than it would be to patch a whole community's worth of bug fixes and features onto the new Google tree.
I think the preferable course of action is that the community should work with Google to see if there's a way to improve the speed of PR reviews.
I'm worried about the chaos that forking could cause in this community that doesn't really have a huge number of contributors yet.
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.
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.
I like Flutter, and Dart for that matter, but I lost inspiration to keep going because it felt like I was learning something deeply that will be dead in a few years. Why not just learn Swift instead? Or if it must be cross-platform, Qt?
Is this the right stance to take? I just want to pick a desktop app development stack that has some staying power, and isn’t riddled with quirks.
I guess flutter web is the "hook" because it promises a "true" cross platform stack, even though imo it is still very lacking.
On the other hand, QT on mobile (iOS, android) is also a bit weird, and comes with lots of restrictions and gotchas. And it basically does not have any support for web apps (except for some super recent, very experimental wasm platform support, that would probably be even worse than the "app on canvas" experience that flutter web offers)
Very sad article to read. I just expect the original Flutter will now die a slow death. I applaud the effort and hope they will be able to find a monetization model that works to support the development. There have been similar projects based on technologies that Microsoft has killed (Silverlight -> OpenSilver and various .NET-based cross-platform technologies) that serve their customers well. Unfortunately, none of them are in any way "mainstream" like Flutter is today.
No, it transitioned it to others after signaling it would for well over a year, so i don't think you could call it sudden:
"In 2011 with the introduction of the Dart programming language, Google stated that GWT would continue to be supported for the foreseeable future while also hinting at a possible rapprochement between the two Google approaches to structured web programming. However, they also mentioned that several of the engineers previously working on GWT are now working on Dart.[6]
In 2012 at their annual I/O conference, Google announced that GWT would be transformed from a Google project to a fully open-sourced project.[7]
In July 2013, Google posted on its GWT blog that the transformation to an open-source project was completed.[8]"
Google funded/helped for some number of years after that.
It still is going, afaik, with gwt 2.11 being released in january, 2024.
That might be the wrong way to interpret this. It actually validates interest in the framework. This change personally excited me and injects some change into the ecosystem that could result in a better future.
Exactly my thoughts. How anybody would take it seriously if the people behind are not known, is beyond me. Anyway I left flutter a long time ago exactly because the mentioned problems - ridiculously slow response time fixing bugs, like auto fill want working.
Our industry has few innovative ideas in past decades ranging from small to large. Rust, React, Tailwind, Typescript, Nix come to mind. All these did things differently enough to seem weird at first.
Flutter is hands down the best DX product with a beautiful language. It is modern Qt and destined for great success given it doesn't get sent to Google's graveyard.
As for the fork, I don't see anyway it not significantly diverging from upstream because bug fixes might involve refactoring which would make difficult to pull in upstream changes.
While surfing around the various repos, I was reminded about the bad taste I got from the last time someone sung the praises of Flutter/Dart; this thing is firmly in the "Android SDK-ish" school of thought: download a shitload of prebuilt binaries from storage.googleapis.com, dontyouworryaboutit
Would you recommend a different distribution mechanism? The Apple binaries are all signed (in accordance with Apple policies), and the team has historically invested significantly in supply chain security. e.g. (a now 2 year old article)
All those words to say that if there was a .github/workflow/release.yml showing the steps required to cook a release artifact that would be the best(?) documentation since it is kind of like a Dockerfile in that it's computer executable but mostly human readable
Of all the different dev stacks I've used Flutter has given me the fewest issues across updates. I've never run `flutter upgrade` and then had serious trouble getting an existing project to run.
Compared to js, react & react native, python, ruby etc I've just never hit the same bitrot so they're doing something right.
Absolutely true. It’s so much easier to upgrade dependencies and if it works / most likely works. We had a small UI regression in a very large app and that hadn’t been touched in 1 year.
> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
Xplat FWs are just technical debt to prove a concept. Once you find critical mass the first order of business should be converting to native so you can remove that entire layer of additional complexity. Similar to paying down student debt to minimize how much interest you wind up paying on them after getting a good job.
IMO this should be the natural order if you size use it at all, not the emergency case.
There are different ways to think about complexity. In terms of the code that's being executed, certainly using a cross-platform framework is likely to result in more complex code as the final output. However, for apps that do not need to use a lot of native features, cross-platform frameworks can significantly reduce the amount of code that needs to be written.
It also means that the entire mobile team can become experts in one framework rather than needing iOS and Android folks. That said, it's certainly still helpful to have deep platform knowledge to debug/optimize in certain situations. But I think the point where using a cross-platform framework stops making sense is going to be very different for different applications.
> That's 50 people serving the needs of 1,000,000. [...] 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.
Ever heard of e.g. curl? Because a billion users use your software does not mean that you have to talk to a billion users.
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".
> The team can't fix the bug without information from me, and it's been too long for me to provide information to the team.
Ugh. I feel like developers should already know this, but I guess not: If at all possible, please, please, please include a solid reproduction case when reporting bugs. That way you don’t have to remember anything about it. (This is also pretty much the only way you can be certain that the problem isn't actually due to your own error/misunderstanding.)
> What do you do if the team won't work on that bug for 2 years?
This is reminiscent of how the Qt Company operates. Qt is super buggy and their bug tracker is full of unresolved bugs from years ago. However, the difference is that if you're a premium user you can pay for premium support to get someone to fix your bug.
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 usable for more would be an initiative I would applaud.
Programming language popularity is hard. The network effects are absolutely massive. 99% of all programming languages are a rounding error away from having zero users. To start to compete with any of the big entrenched languages seems to require either:
1. An extremely easy migration story so the language can leverage ("parasitize"?) the existing ecosystem of another alread popular language. That's C++ for C, Kotlin for Java, TypeScript for JS, etc. This is definitely the easiest path to success.
But it means your language is significantly hampered in its design because of the need to be compatible with the language it's building on. This is why C++ is still failing to be a safe language and is a sprawling mess. It's why Kotlin has type erasure. It's why TypeScript, despite having a fantastically complex type system, is still unsound and can't use types to compile more efficient code.
2. A compelling platform or framework that developers want to be on so bad they'll learn a new language. Rails for Ruby, iOS for Objective-C and Swift. This is the harder path but it means the new language is less shackled to a previous one and can be more innovative.
Dart took the second path. I agree it would be nice if Dart had more pillars shoring up its success than just Flutter and I hope we get there one day. But one successful framework is more than most newer languages have and you have to start somewhere.
I'm obviously biased, but I think Dart is a good general purpose language and would work well for many different domains. But fighting against the network effects is hard and growth takes time.
Well, I hear that there's a foundation for it, so: new leadership, new rules. I can't tell from the outside how much of Flutter/Flock is deeply tied to Dart versus it just happens to be a bespoke language because 20% Time exists
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.
Yeah not sure why this is downvoted it is true, a lot of the open source tooling for ios is built in ruby and plenty of people build scripts and cli tools in ruby.
I'd like it the other way around and want to see Flutter APIs for other languages (lets say Kotlin). Personally I feel no desire to learn Dart to use it only for Flutter.
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I'd love to see some examples. I've had my pull request merged in a fairly quick amount of time - less than one release cycle, which is what matters here.
Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller). So it's hard to take this announcement seriously.
> Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller).
For me its so weird they ditched google/skia to develop Impeller in Dart from scratch in the first place. If skia was not ready they could move just 1-2 developers to Skia team to collaborate with them. Now they want to even write their own 3d rendering lib based on Impeller (flutter_gpu, flutter_scene) even thought google has already mature 3d engine in C++ (google/filament). For me from the outside looks like "not envented in our team" syndrome. We are now in funny situation that react native has react-native-skia and react-native-filament and Flutter teams reinvents the wheels.
As someone who has slowly been writing Dart/Flutter bindings for Filament[0] over the last couple of years, I agree the internal 3D engine was a bit of a strange choice of priorities.
They been building it before and still building and releasing with flutter so it's not like they don't have pipeline for that. And it was distributed compiled so nothing to compile for 3rd party users.
- guy wants to add PR more aggressively to a code base than Flutter currently is
- isn’t clear if they have a concept of handling compatibility between fork and original
- why not be a labor organizing entity and work with the flutter team?
Some of the PR that I am aware of that are stale and could be good candidates - are difficult design decisions and stakes need to be put in the group.
It seems ill advised. This is huge amount of work with limited upside and huge downside (adding uncertainty to outsiders looking in) and tons of effort (just in infrastructure maintenance).
Edit: if I were conspiracy oriented I would think it’s to harm community. I would pay this no mind.
Note that I know nothing of the Flutter team/culture and am only answering generally:
>why not be a labor organizing entity and work with the flutter team?
Depends on the maintainers/team. I've definitely seen many a bureaucracy that slows down FOSS to a crawl of bug fixes and feature progression. If you make enough PRs that are ignored for weeks or months, you'll realize this isn't really a team ready for nor interested in a proper FOSS environment and it's instead mostly "that teams code that happens to be readable".
Their official answer seems to suggest as much:
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I guess we'll see. I'm way more of the mentality of "actions speak louder" so I'm not really one to announce my plans until I get something worthwhile off the ground (in this case, a few stale PR's that feel like game changers to the customers). But that's not a mentality modern social media rewards.
There is a comment above that shows the founding former didn’t want to fix tests in his PR. Flutter is massive and it’s critical infrastructure. The tests are critical to up-keep. The tests are probably a majority of the work. Which makes sense for something that has such a large surface area.
I think this is an emotional reaction from someone has never managed a large project. Merging PRs and releasing them isn’t the problem. I hope they understand that.
Flutter is amazing. Web, desktop and mobile that actually work is nearly magical. Yes there are priorities. Yes the desktop isn’t as high priority of web. It does work. Hell. Collect money and fund Hixie or others to prioritize patches community feel should go in. That is constructive and methodical/reproducible.
Forking a massive code base, applying PR and not conforming to the source repo standards (tests whether that is golden or not) - just seems not well thought out.
I think community could fund a well known developer to fix desktop issues and have PR adhere to Flutter standards. It’s a ton of work. But seems like it’s a money/dev/process issue. Not a PR merging exercise.
It's such a shame mobile development with C# isn't more viable. I want to make some apps, and I hate JavaScript, but from everything I've read Maui just isn't practical.
The native approach is quite viable: my MvvmCross-based app has been on both stores since 2018 with almost zero MAUI/Xamarin-related issues, even with hundreds of thousands of installs.
Not gonna lie though: building the UI twice for both iOS and Android feels somewhat masochistic. But in the end, it "just works" with shared View/ViewModel logic on both platforms.
> Imagine that you're the engineering director, or CTO of a company whose next release is blocked by some Flutter bug. What do you do if the team won't work on that bug for 2 years?
Then you fix the bug? If your team can't then pay a consultant who can? Isn't it open source? What did I miss?
I couldn't agree more,
"""In other words, I believe there are blind spots because Flutter team members don't actually use Flutter."""
Electron creators made atom, the best text editor, and then vscode,
And flutter doesn't have a signature app to show that it can be used for serious purposes.
Currently, the most famous open source app in the community is appflow.io, I compare the current state of appflow.io to the current state of flutter, even the unfixable bugs.
I compare vscode to the JavaScript ecosystem, with both advantages and disadvantages,
> sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
This is what's wrong with companies trying to do OSS. They are literally unable to get over themselves and tap into the one quality that makes OSS so worthwhile: tapping into third parties volunteering their time, creativity, and ideas. The need to tightly control direction and strategy of a project leads to companies putting up walls that make it hard to tap into this.
IMHO, Google made several mistakes with Flutter that stem from their "not invented here syndrome". Effectively they've been competing with their own people on things like Kotlin, Kotlin multiplatform, and now Compose Multiplatform which is emerging as a direct competitor to flutter (does the same things on the same platforms). The obvious move years ago would have been to open up the flutter platform to other languages than Dart (especially Kotlin) and share code across both ecosystems and make the combined solution a better one.
That never happened. Dart is alright but in the end it's just another Java/Kotlin like language. IMHO Kotlin is nicer. But that's just me. Interoperability between Swift and Kotlin native now exists on IOS. Compose works on IOS. But Dart-Kotlin interoperability is not a thing.
This is not some kind of oversight. This is so obvious that it must have been proposed, multiple times, and blocked by Google management for internal political reasons. I have no other explanation. Any technical blocking issues would have been fixable/addressable. They chose not to. And now Flutter is de-prioritized internally and the team reduced in size because Google created another dead end. This is self inflicted failure. It took an outside team from Jetbrains to take Jetpack Compose and turn it into the multi-platform solution it is now becoming.
A foundation with a fork is the right move. Fix the above and great stuff might happen. Google doing things alone isn't working for them. Repeatedly. They need outside help. It's there for the taking. They should not fight this foundation but back it with money and transfer the entire flutter team to it.
With SwiftUI the gains Flutter had (on ios) are diminished. Flutter was way better than ObjC and the nasty layout thing ios apps had before, but today swiftui is really good.
It really makes me wonder how and why Microsoft and Google can't create a cross-platform GUI ecosystem that lasts. Like, they both will have multiple operating systems and platforms such as web and mobile in use at their company and no doubt build a huge amount of bespoke tools. Wouldn't it behoove themselves to create a cross-platform GUI solution that actually works, is maintained, etc.?
I have been looking into building one myself, and for a company the size of Google or Microsoft, the task almost looks trivial. But somehow, they create these huge monstrosities like Flutter and .NET MAUI that crumble under their own weight.
This is especially true for Microsoft who sits upon two of the best languages around in C# and F#. Flutter often has a tough sell because it comes with Dart and vice versa. For Microsoft, is it really that hard to have a three-tiered approach to cross-platform development in that there is a separate, dedicated platform for each of web, mobile, and desktop that share common components (like drawing and animation APIs), architectures, paradigms, and of course languages?
GUI development on desktops is just a complete mess right now. Qt Quick with QML is okay, but it has a huge amount of strange limitations and has a surprising lack of just plug and plug UI components, like charts. Plus, you have to use either C++ or Python. Flutter seems better but also suffers from the lack of professional plug and plug widgets and requires the use of Dart, which is even less ideal. Plus, it requires the support (or lack thereof) from Google. For Microsoft, I could list at least half a dozen cross-platform approaches in a single blink of the eye.
I wish it was just native platforms. Someone needs a faster development and reaching the customers, just use web-views and then bring on native when you have the money, developers, and users. Interacting with non-native apps has consistently been a subpar experience without fail.
I'd rather put my money behind KMP by JetBrains. It has a more streamlines, practical, and consistent future than flutter, react native et al.
| How many Flutter developers exist in the world, today? My guess is that it's on the order of 1,000,000 developers. The real number is probably higher, but one million should be reasonably conservative.
one million flutter developers? that does not make sense to me at all (by orders of magnitude). does anyone know any metric to validate this? i am shocked if it's true.
This is a welcome fork. Still for me, flutter is not web platform friendly by design(e.g. javascript) and that's the reason I stopped using it and switched to react-native + electronjs(react), they seem more reliable and production ready, plus this approach is totally web friendly.
Weird, I'd never heard of Flutter (or at least it never registered), but then I'm an infra engineer, so why would I have? But particularly strange is that if you go to flutter.dev, you'll notice you can't find anything about who Flutter is. There's no about page with links to the people behind it, or any indication of what company sponsors it.
Then this flutterfoundation.dev site... weirdly also doesn't say who's behind it. Presumably some outside folks? Maybe just the one person who wrote this blog post? But if it's called "Flutter Foundation" I would expect it to be more officially sanctioned?
Were I in the market for a UI framework, none of this would make me feel very confident.
“Supported by Google” doesn’t communicate “owned by Google”, and anyway, marketing text in the middle of the page is not particularly telling. I expect a site about some technology to have an About page with some information about who is behind it and who funds it.
Compare https://go.dev/project which explicitly mentions that Google runs the show. The front page makes it clear that Google runs the language’s cloud infra. Plus there’s the Google logo in the footer.
The Flutter page never mentions who runs it. If it’s independent but sponsored by Google, there ought to still be people involved. If it’s owned by Google, it should be clear about it, and not just indirectly mention it.
I believe this kind of issues happen in Google everywhere. Not sure who to blame for, but it’s definitely a severe crisis Google is facing. Google should spend time fixing it.
>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.
The most important thing I wish this doesn't cause is to divide the community, but the article addresses this.
I enjoy Flutter a lot, it would be very sad if it got discontinued. An previous employee at Flutter just showcased how powerful the framework can be outside it's main usage. https://www.youtube.com/watch?v=fU6d81MurTQ
> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
Yeah this isn’t drive-by contributions where you shit out a PR that works for you but makes the test infra fail and you get upset. Ppl need to think big picture.
One big problem, I think, it may not be visible all of the test infrastructure if your outside google. Don’t know. Gerritt is its own world and googlers live there not in GH (it appears).
The main problem in projects like flutter is to always focus on the "new". If you focus on the new without stabilizing the existing basic features, you will accumulate thousands of problems. If the same path is followed in this new project, I think the result will be the same. There is still no clear update on issues opened years ago. and most are pretty basic needs.
> 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!
Given that you could probably make a similar assertion about any popular framework, this doesn't strike me as particularly relevant.
This kind of PC-jargon also makes me want to place a bet that the alleged "monoculture" is some perfectly reasonable insistence on either clarity or basic politeness. Willing to be proved wrong though!
I must be living under the rock. I thought Flutter is prosperous? I only dabbed into Android development as a learning experience so I probably missed something important.
If everything the article says is true, should I switch to Kotlin?
Instead of forking popular libs, someone should think how to improve OSS model. I think it is wrong when projects with 1mln users are not self sustained
Honestly makes sense to me. If Google has proven one thing is that it generally maintains a very tight grip on anything open-source that they ship. Ie. it's extremely hard to contribute upstream. This is fine when it's a package that's critical to good, so they invest a lot into it (for example, Jax). But for stuff that's not quite there, it means fixes will meander for months if not years.
Sounds like Flutter core teams hold contributors to a high standard and the Javascript bros can't deal with real Software Engineering so they're having a party of their own.
In all honesty, good luck. It might be useful if it never breaks compatibility with Flutter.
I invested quite a bit of time working in Flutter years ago. The team overpromised and underdelivered. Felt like it was all marketing fluff and I'd been duped.
> 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 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.
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.
Every project is different. Claiming it needs more developers because "it needs to emulate UI of six platforms" as if that justifies a larger team is also fallacious.
I wanted to see the evidence that the community is lacking support and/or flutter is lagging behind competition. That would justify Flock's goal... Otherwise, it sounds a lot like both naivette and a unpublished agenda.
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.
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.
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.
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.
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.
You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.
Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.
It does, however, have bearing. Despite how common the practice may be in the corporate world, developing a framework without any regard to the user experience thereof is pretty suboptimal
Not sure this is a good comparison because the PHP Foundation is "relatively" new and afaik there's no strong correlation to "the php development team" besides these people being paid and also work on it. PHP had a 20y history before this foundation, and the main difference is that it was never steered directly by one big company. Zend, yeah, but they had influence, they had neither started the project, nor ever had a long-stretching majority of people in the important positions. (Disclaimer: have not been an active part of the project for a couple years)
Flutter has much bigger scope than PHP Foundation. It's more fair to compare PHP Foundation scope to Dart Lang and Dart SDK. Flutter scope on top of that is Flutter Engine, Flutter Widgets, Flutter Framework, Flutter Packages, Dev Tools (IntelliJ + VSCode). PHP also support desktops/server environments instead of Flutter 6 platform (iOS, Android, Windows, Linux, MacOS, Web). Making crossplatform UI toolkit is the most labor intensive - PHP Foundation is not developing that. PHP had also 2 decades ahead of development.
In general in PLs this is not true—the standard library is usually very carefully designed and all of its interactions are well-considered—but Python's libraries do seem to be more independently-updated than most.
Even so, isn't that an argument for a smaller, integrated team for the framework, rather than a large one made of ~1000 volunteers? A tightly-knit framework is much more likely to suffer from too many chefs than a disparate collection of library functions.
Between the parallelization problems inherent in a tight framework and the fact that its total surface area is also smaller than a PL that's maintained by about the same number of people, it sure doesn't sound like Flutter's problem lies in developer headcount.
I doubt that complexity of a language is comparable to that of a widget library. After the text input cell and scrolling window it’s basically dumb geometry/drawing code all along.
It's much harder to to implement a language in a proper way than writing a widget library.
But that hardness comes from the level of knowledge one must have in different fields such as compiler theory, cathegory theory, hardware, beside classical computer science and coding.
To write a widget library you just have to know how to code and have some experience.
That being said, the amount of work for implementing a widget library might be higher, but is less qualified work being done.
I dabbled in computer language theory and compilers and it's hard. I have no issues reading source code for widget and GUI libraries.
The Dart team is separate from the Flutter team, though they do interact as Flutter is now the primary use of Dart and as such, influences what is worked on in the Dart team.
> Even whatsapp had about 50 members when they were handling billion users
I would add that running a service deployed to N regions is considerably more demanding and work-intensive than working on a releasable software package.
No one working on Flutter is woken up in the middle of the night by a pager because a user was not able to install a package, to then create a call to pull in half a dozen of Flutter engineers.
Python doesn't have a narrow scope. At least compared to Flutter. It's in so many places, from Linux installers, to medical, aerospace, math,... and finally the web (which is probably what we hear about the most).
I did not meant to start a pissing contest, I thought the biggest idea was that Flutter isn't 35yo and because of it, it's more likely to drastically change, and in a fast way too.
> 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.
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.
I can understand the test frustration on both sides.
* He's being asked to fix tests that were already failing. That can be an enormous task depending on the nature of the failure and the code base.
* The team doesn't want to merge his PR since they don't have a test. The code is presumably working without his PR and understandably they won't change a single byte without seeing tests work.
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.
Really not a fan of the flutter concept. “One codebase?” Ok, so how does that make a great iOS app that takes advantage of the full device? Basically coding to the least common denominator.
Hire a Swift person. Hire an Android person, and build things in a way that gets the most of of the device. Otherwise, what’s the point of an “app” in the first place. Can use a website if “one codebase” is a goal.
> 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 replacement (just configuring FVM - Flutter Version Manager):
Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell. And the frustration described in the post is felt by many CTOs and developers. Especially those who use Flutter for desktop and web. Flutter provides an amazing experience for desktop apps, and precisely because of that, it feels so frustrating when you stumble upon some stupid bug that has been open for a year or two and never gets prioritized. Usually, it's nothing critical, but still requires workarounds and wasting time.I don't know, the idea of Flock sounds good, the main question is engaging the community. Hopefully, the author (who seem to be an ex-Flutter team member himself) have a good grasp on the state of the community.
Wishing luck to the project and going to keep an eye on the progress.
> 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 the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.
Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.
[0] https://flutter.dev/showcase
Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.
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 people just don’t care about platform idioms, and b. the choice is often a non-native app or no app at all.
Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter at all and flutter even offers a pretty good cupertino scaffold package that does this animation.
"cupertino" is the name of a Flutter widget set, not of the native platform controls or L&F.
Few Flutter apps are going to use cupertino because the whole goal of using Flutter is to create cross platform codebases to save development effort. To use an alternative widget set per platform is a huge amount of additional work, and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.
> and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.
That is a bizarre fact.
The two things that stick out the most to me are navigation behavior and text fields. Cross platform frameworks seldom get either right, with react native being particularly bad on the navigation front.
There are variances between Apple’s apps but they’re all using some combination of UIKit and SwiftUI regardless which limits how “wrong” they can be.
You’re completely right, but that doesn’t change the fact that I think it’s a bad idea. For a company that used to care so much about user experience, Apple has been throwing a lot of it out the window in recent years.
Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.
You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technical reasons why, but when you talk about the annoyances it is easier.
I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC
In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for desktop and phone but not so for Windows and Android, so you have to make a choice at that point.
> The vast majority of people said they wanted apps to act consistently across devices
You shouldn’t trust what users say they want. It many times doesn’t correlate with what they want. Certainly, I would try and figure out what they mean with “act consistently”. My suspicion (for which I have zero evidence) is that they’re more talking about high-level similarity than about nitty-gritty details such as how many milliseconds to hold your finger down to select and edit text, how scrolling works, etc.
Also, I suspect they want devices to act constantly across apps, too: copy-paste should work, text editing should behave identically, sharing controls should be the same, etc.
In the current world (and, I think, in any world where there is competition in any form between platforms), they cannot get both, so then, it boils down to what is more important.
For me, that’s platform consistency. For example, I find it easier to get used to text editing being different on a phone and on a laptop than to get used to a zillion minor inconveniences/annoyances in typing and editing behavior between apps.
I also find it less of a problem if text and emoji look slightly different on a different device than when they look slightly different between apps.
> You shouldn’t trust what users say they want.
How should I interpret the following four paragraphs where you say what you want?
If you have zero evidence against the mountains of evidence I do have, why should I be convinced of your argument. It seems like it is you who are talking subjectively about what you want and then applying that to everyone else.
I find it very hard to believe that majority of people prefer app consistency over platform consistency.
One example, I'm pretty sure there are thousands more: Why does every UI detail, except the logo, of Spotify looks and feels different in Android, Android Auto and PC/laptop? Because Spotify did not study what the market wants?
Spotify looks much similar between devices than it does to any specific platform. Does it use Material on Android and Fluent on Windows? No, it uses the same sort of styling on both. Don't mistake UI changes for screen size responsiveness, for actual platform specific nativity.
> The vast majority of people said they wanted apps to act consistently across devices
... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use).
Certainly there is some overlap between look & act: a platform-native "dropdown menu" looks and acts a little differently on Windows vs Android vs iOS. But I think these differences are not in the majority, and when users say they want apps to "act consistently" across platforms, you an absolutely achieve that with native UI controls, and it's not even that difficult.
This is a big problem I've run into when doing user studies myself: you need to be very precise with your language when asking users questions, and even then you often need to dig in and ask for details about what they mean by their answer. And of course having visual examples and functional mockups for users to play with helps a ton.
Another problem is the leading nature of questions you might ask during a user study: if you simply say "do you think it's better if the app acts consistently across platforms", of course users are going to say "yes". Saying "no" to that question feels kinda stupid, TBH. But if you were to give a user an iPhone and Android phone, with the same app, using native controls on both platforms, and ask them if you believe that the apps "act consistently" with each other, users are probably going to say "yes", as long as the design and UX of the apps in general are consistent with each other.
(And even that's a contrived test: very few people use both an iPhone and Android phone regularly!)
You can achieve them with native controls but only at the bottom-most layer, if you actually want consistency. Spotify for example does not use Material on Android, Human Design Guidelines on Apple, and Fluent on Windows (well, they use Electron, bypassing native desktop entirely), they use their own custom controls that may at the very bottom layer be based on native text inputs, but they rebuilt all the actual UI stuff from scratch to achieve a unified look and act.
This is all well and good but the people I see on HN are ones that say that the app should actually look native on each platform, ie Material on Android etc. This opinion is what I'm pushing back on, not the fact that ctrl + C works on Windows and CMD + C works on Mac.
Of course, this is the reason why cross platform frameworks are so popular, if you're already gonna have to rewrite the UI for every platform, why not just do it once and save yourself the effort? After all, users won't care, as they've shown, because they care much more about new features coming out. There are always tradeoffs because time is finite.
> This is a big problem I've run into when doing user studies myself
Sigh, do you really think that all of these weren't considered when we did user studies? This is like 101 material, frankly almost insulting to imply that we didn't, therefore it can justify your priors, even though I agree with your points to some extent as said before.
It's not the end users that care about the uniformity but the fact the corporate design team wants there to be uniformity across all their platforms they support. This is part of branding and user experience. I'm not arguing for or against, just stating that is where the push for this comes from. It would make support, for example, easier, if all versions of your app user experience were similar.
This is very true, and it's a PITA when the corporate design team doesn't know anything about mobile design and thinks mobile apps are just "Honey, I shrunk the web app" with some Figma plugins to help. It can be an uphill battle to get them to compromise.
I'm not quite sure why this was downvoted. It's true.
It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.
Right, but you continually conflate "unified experience" with "using custom UI controls".
I never said they must be custom, merely that custom makes it easier to implement.
It doesn't seem to mention it being done against anyone's will. It's definitely true that a company can save money by only needing to maintain one set of help instruction screenshots, for example.
Ever since the release of the M1, the number of Android users who now use Macbooks as their laptop has sharply increased. Even moreso for work purposes.
I use MacOS, iOS and desktop Linux regularly and much prefer apps that act the same on them all.
Maybe 40% of the developers I know use MacOS + Android.
Hello! I use three platforms on a daily basis. I vastly prefer my apps to be reasonably consistent with themselves rather than trying too hard to adhere to the platform.
My wife is on two. Most of my friends are on either two or three. In fact, I'm pretty sure my parents and a few coworkers are the only people I know who are exclusively on one platform.
Many (most?) people don't have a clue as to what the particulars of any given platform even are. They know how to get around in each app they use, and maybe the web browser, and that's it. Lots of gestures go completely unused.
> I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms.
It's not even a single person that has them, but I think we have all had the experience of family or friends that need assistance with something but they have a different type of phone whose organization and workflow is completely different because it's native. You literally can't help in this scenario without having physical access to the device.
I've genuinely never heard of such annoyances from actual users (at least not from most users, who aren't power users, and even then, not even from the power users), and most cross platform frameworks already hook into the native APIs like for the back button, so it'd work the same either way.
Out of interest, do you know many seriously vision-impared people?
Windows, and Mac OS X in particular, have quite good support for accessibility if you use their built-in GUI systems, and unified UIs are often (not always, vscode and chrome are quite good, for example), very bad, sometimes just a black square as far as accessibility goes.
Many cross platform frameworks have good accessibility support, not sure what that has to do with native platforms, as the cross platform solutions simply hook into the native platform accessibility APIs anyway.
https://docs.flutter.dev/ui/accessibility-and-internationali...
I didn't know flutter had such good support, and I'm very happy to hear about it!
Unfortunately, most cross-platform frameworks have awful accessibility support, I've looked at various in the past and just found failure after failure. I am now going to look harder at flutter.
People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.)
It is exceedingly rare for the multiple devices to span the UI toolkits of more than one or two company-platform. For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
Regardless, "unified UI" doesn't mean it can't use native controls. More important from a UX perspective is that controls are in the same places and behave similarly, and that the app is organized in a similar manner, plus or minus what might naturally change because of differences in screen size and input method. And that's another useful point to make too: mobile, tablet, and desktop experiences are often quite different, and that's normal and expected at this point.
Another consideration: it's a lot more difficult to make an accessible app when you draw your own custom UI controls with your own custom behavior. If you use the native UI controls, you get a lot of the accessibility features for free, and have to do much less work to make sure everything works for people who are vision or mobility impaired. From what I understand after reading about blind people's experiences on various platforms, most companies that do custom UI don't bother, and the accessibility of their apps is atrocious.
I think you made the same points twice so refer to my other reply regarding your first few paragraphs.
> For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
I have not seen evidence among normal people that this is true, given that the most popular apps all have custom UIs that don't necessarily follow Apple's HIG, TikTok for example. Regardless, the point is that if you're making an app for every platform like iOS, Android, Windows etc, you must make a choice lest you exclude all non-Apple users for example. ByteDance does therefore indeed use Flutter, based on this (at least in some capacity).
> mobile, tablet, and desktop experiences are often quite different
Don't conflate unified UI to mean non responsiveness. Look at Spotify, their UI is essentially the same in design except it is responsive among mobile, tablet and desktop, all while not looking native at all on any of them.
Regarding accessibility, many frameworks can be robust in that simply because they hook into the native implementation anyway, so I'm not sure where this trope of not having accessibility comes from. Here is Flutter's for example, with a dev in this thread also having talked about how they have one of the most robust implementations of accessibility that they have found among any framework: https://docs.flutter.dev/ui/accessibility-and-internationali...
I think the problem with the same app following native app idioms is that now the support and instructions behind that app will have to be different on every platform.
E.g., if you have Instagram on your iPhone, an Android user won’t be able to tell you “just click on this, this, then this to change your XYZ setting” because it will be in a different place than the Android app if developers follow native conventions 100% of the time.
The fact that Spotify or Instagram or any of those other platform-agnostic apps look and function the same on every platform is a huge benefit to practical usability.
I think the only time when nativeness matters is when you have an app that’s doing stuff that’s closer to being “low level” to operating system features. For example, an app that performs file system management, I don’t want that to have the exact same UI on Mac, Windows, and Linux, because those platforms have different conventions for where things go and how files are represented.
> 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 can smell a framework app.
> 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.
Do you only use Apple devices? That may be why, because statistically most of the world's population uses Windows and Android where there really isn't a concept of "native" because they each have a few different UI frameworks.
There was a time it looked like cross platform GUI toolkits would get us there, but things went in reverse.
Do you hear people complain that __websites__ have different aesthetics?
I used to share your opinion but since the web I think it is great that designers can have original designs and I started to worry about more important things.
I agree. What doesn't get enough attention in these often dogmatic debates is that there are some native conventions that are hugely important for usability while others are mostly irrelevant.
E.g, I have to use a Java app on the Mac that uses Ctrl+V rather than Cmd+V for paste as well as other Windows/Linux keyboard conventions. This is extremely jarring.
Web apps never do that. Browsers are pretty good at using native conventions where it matters by default. Of course web devs sometimes go out of their way to vandalise the browser's perfectly good defaults - e.g. by overriding scrolling behaviour.
Surprisingly, some of Apple's own native apps (such as Numbers) break platform conventions in ways that makes the app extremely inconvenient to use.
The web is interesting because we never had rich components provided by the browser to begin with. Web applications have always had to draw everything but the most basic inputs themselves, and the design of web apps has evolved accordingly.
In an alternate universe, where web apps were embraced by the platform from the start rather than something people had to shoehorn into a document sharing mechanism, and we had rich components built-in, then yes I would probably be annoyed if people insisted on rolling their own versions. After all, I am annoyed when people use a span with a click handler instead of a proper anchor tag, because it usually breaks middle clicking or opening a link in a new tab—a platform convention I have internalised and expect to work.
Note this only applies to web apps, not sites. Much like how I do not have any problem that magazines don’t share a common layout.
> Of course, I recognise that, a. most people just don’t care about platform idioms
This is the big one. HN commenters are not representative of the average user. You'd have to specifically point out the differences for them to even notice, and even then they simply don't care.
Casual users don't care about the app "looking wrong". They do care about the app not working like other apps on their phone, though.
Casual users do care about app behaving wrong, though.
If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave.
They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame of reference (vendor-supplied native apps).
Is there a concrete example of this? I still only hear this on HN where some mythical user gets annoyed about copying and pasting (most apps don't allow that, even, like TikTok or Instagram, which are the apps where most users spend the most time). Like the sibling commenter, I only have seen whether the app does what they want or it doesn't, most don't notice any annoyances unless they're really looking for them, which they're not.
> I still only hear this on HN where some mythical user gets annoyed about copying and pasting
Perhaps they're not complaining because they've just accepted that it probably doesn't work and so don't even try anymore.
My SO has stopped trying to copy/pasting stuff, I now always just get screenshots, both from mobile and her PC.
At work, almost none of the customers I interact with copy/paste stuff, they send screenshots as well. Like, "can you send me the order number?" will result in a screenshot of the order number control, or often just the whole order window.
I've not found this to be the case at all. They only seem to care whether the app does what they want or not.
Granted this is my personal experience, I can't say this is the case for every single user out there.
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 built the understanding that users dislike non-native UIs?
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.
I've built apps with pretty high retention rate so even if they're annoyed, it doesn't seem like they really stop using them. Mostly though, based on user feedback we collected, not once have I heard anything about UI complaints. It really feels like this is a common refrain on HN about what HNers think happens in theory versus what actually happens in reality wrt user preferences.
Note, this has nothing to do with your app or this specific discussed GUI, but this is something I have noticed over time...
I think that what is commonly seen by devs as complaining and being overly concerned with details that don't matter is instead a some of the time advocacy for doing things the right way for the sake of it. It is totally possible to build things that meet the bare minimum requirements for user retention and for people to not complain, but that doesn't mean that it is optimal. You can build Soviet style housing blocks that people live in that are completely functional and that no one will have any problem with, but the quality of life is degraded as opposed to what could have been built.
It can be tough seeing through the grumpy nerd 'I want it my way because my way is best' and finding what is actually 'this is a good thing that we should be doing, and if we did there would be a marked improvement for everyone', but I would not forsake one due to the other.
It's more than there is no evidence of an issue, so why pretend that there is? The "right" way is entirely subjective, unless you can give me some objective criteria for what it should be.
The issue in this case is pretty plainly that the application does not subscribe to the conventions of its host UI. I'm sure there is no objective reason why we need to conform to any convention, except that there is one.
Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.
I'm sure that Soviet architects would have agreed with you.
Perhaps so, as different cultures have different tastes anyway. That you don't like Soviet styles is no indication of whether people in the Union did or didn't like them.
I think it may be true only for the apps that are easily replaceable.
Why would an app not looking like a native app automatically be seen as badly implemented?
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. Same company, same underlying technology (Electron), but Code is good while Teams is awful because MS invests so much more in Code. Even so, Teams-type apps are what tends to come to mind when people think of Electron apps because those are so much more common.
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.
In my case there is another reason - if it looks cross platform it is probably taking up more resources than a native app.
I used to think this, now I think nobody cares except people "in the know"
Every time I've ever mentioned it to anyone they really didn't seem to understand or care
It really feels like an "HN bubble" type argument, I've literally never heard it outside of HN.
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 happen to have created a great native experience. And since most apps don't, I don't use them, and I don't have a lot of apps as a result.
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.
As an on-again off-again (currently off-again) cross-platform app developer, I always want my app to look like it fits in with the rest of the apps on whatever platform it's deployed to.
As a user, I hate it when some app developer thinks they're cute and wants to skin an app differently or draw their own ad-hoc widgets.
Developers who think that way have no clue what their users want. Most iOS users want a native experience, not something else. When I see an app that doesn't have that, I quickly lose interest. Having the app look the same on all platforms is a dumb idea to start with.
Funny how you are calling people clueless while being confidently incorrect. You're in absolute minority.
Are these the same users that prefer websites without CSS?
Websites and apps aren't directly comparable when it comes to this metric.
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.
You still have to deal with the Android build system, `flutter new` just generates initial config for it and all the other necessary metadata (and that config can change between versions - I ended up manually diffing the generated stuff against a new app every time I upgraded).
At some point I made the mistake of not touching the code for too long and upgrading Android Studio when suggested, and I was never able to (find the time needed to) get that app working again.
Ah gotcha, I thought it was papered over a bit more with Flutter's tooling. Good to know.
> 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.
Typically people just make the app look and work the same in all platforms, like how you might expect a responsive web app to be like; no one is implementing Notion with a platform specific UI, for example, using Apple stuff on Apple devices or Windows stuff on Windows devices.
> 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
You may notice that the first reference is from java, and i bet js lifted it from there. They may have been aware of java because they lifted the name too.
The other two are too new to be relevant.
Flutter uses canvas when targeting the web. (At least it was the last time I looked at it years ago)
Canvas is the javascript name for writing directly to a frame buffer :)
There is a world outside the browser. For now.
Canvas predates javascript. For example, TCL's TK toolkit uses Canvas[1]
[1] https://tkdocs.com/tutorial/canvas.html
Flutter showcase is a disgrace, to be honest. Doesn't represent the actual landscape even remotely.
That is good to hear and hopefully gets fixed. It has been some years now, but I did use flutter for some toy projects and liked using it - I am used to using ReactJS I found there was a lot of transitive knowledge coming from that background.
Ultimately what dissuaded me from pursuing it for any bigger projects is a lack of examples of great looking production apps with complex requirements. When I was looking, I was seeing a lot of CRUD apps - display a form, click an upload button, ect. This was probably 2018/2019 when I was taking a serious look at it.
All of that is to say: Quality app showcases do matter for whether or not devs will trust a solution enough to pull the trigger.
I don't know how to fix the showcase problem. With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible. And there are zero incentives for developers to send their apps for screenshots. You just ship the release and move on to the next tasks.
I also discovered Flutter in 2018, and it kind brought joy into UI programming for me. I rewrote all web apps I had with Flutter and published a bunch of mobile apps, but the coolest thing is that I routinely make apps for my own (or my team's) use.
For me, Flutter lowered the costs of UI app development so much that I could just spend a weekend making some neat, small, practical tool for my own needs. I really love making these "private" apps – no need to care about all corner cases for all users, no need to polish design for all screen sizes/font sizes. Don't even need to be released (TestFlight at max, if doing it for a team). It's just fun, and I wish more developers could have the same experience.
> I don't know how to fix the showcase problem.
This is trivial for any team that provides a framework/platform and spends any amount of time engaged with their customers - you know who your prestige customers are and you show off examples of the products they have built with it. The state of the showcase is just reinforcing the points made by the OP.
> With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible.
Seems like it is: https://play.google.com/store/apps/details?id=com.fluttersha...
On Android you can also tell the way the list scrolls. Especially on devices, 2-3 years older.
If you're referring to the increased scroll speed with two fingers issue, that was patched within the last year.
Unfortunately, not talking about that.
Don't elaborate or anything.
I think they're referring to the extra frame of latency when scrolling on Android. But then again, I've literally never heard anyone complain about that, I honestly don't think anyone notices, I believe the GitHub issue had to use a slow motion camera to even capture the issue.
You'll notice it on higher refresh rates.
Sorry, but do you really develop your software as a professional engineer based on "I heard X from few people"? With all the bias and filtering your brain does for this kind of "metric"?
Do you not? Engineering is a tool for solving human problems. If humans don't have a problem, then there's nothing to solve. Engineering is not the end in itself but the means to an end.
Over time I have become convinced that the, fit in argument is not something that actual users care for.
The sometime subjective aesthetic reasoning doesn’t mean the application can’t succeed. office ribbon is an example
A lot of users do care for fit and finish, but stick around with crappy UI because it’s not worth rage-quitting over.
They do move when better UI + same-ish functionality comes along.
The one sort-of exception to this is Enterprise Sales, where the people buying the software don’t always use it. But even there, corporate purchasers do get flak in annual reviews / feedback cycles for especially crappy enterprise software — so even there, especially crappy UI will catch up with you.
But the question is will they move from a Java UI to a native windows UI, all else being equal. What if the Java UI is better ? What if the Java application is better
I think you are correct, but I think your example is a bad one. Most people do not have a realistic (their employer will use it at work, it even occurs to them that they could use something else) alternative to MS Office so will use it whatever MS does.
I miss the days when applications had their own look and feel. If your idea of great design is identical rectangles to all the other apps, I guess Winforms solved that use case 20 years go.
It’s perfectly possible to still have a unique look and feel without completely forsaking all the platform affordances. You get a lot of stuff for free or very cheap building using the platform toolkits: stuff that people internalise and expect to work without even realising it. I think it’s a bad idea to throw that all away.
Just like a lot of the "web application packaged as mobile app" frameworks did in the past, except with ugly iOS styling that also completely mismatched the expected navigational patterns.
What's worse, there are new applications with custom look and feel that do the same navigational sins today
On non-mac platforms material is already everywhere so they mostly don't look too out of place.
The developer could use the cupertino framework for iOS releases, but usually choose not to.
Sounds a bit like plastic surgery... you only notice the bad ones.
> but they don't fit in.
You seem to say this like it's a bad thing?
I think it is, personally. Mostly because common UI appearance and paradigms makes software easier to use, especially for non-technical users.
But in this specific instance I was referring to OP’s claim that it’s impossible to identify many Flutter apps, which I dispute.
I think people might be talking past each other on this issue. If you are on one platform only, then yes having apps behave the same is nice for muscle memory. However, if you're using multiple devices and platforms, then I want Slack to work the same regardless of device, I don't want iOS native navigation on the iPhone and Windows native navigation on the laptop.
> You can't be serious.
Please keep your comments civil
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
I was a Flutter early adopter going on for like 7 years ago now, and Flutter has its place, but I don't know if I could repeat your sentiment with a straight face. Especially when comparing it to Qt.
flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....
If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean impossible, design limitations of the web platform that in some cases fundamentally cannot be relaxed and in others are very unlikely ever to be. With this direction, scrolling will never be good, text rendering will never be perfect, input and manipulation will never be acceptable, links will never work properly.
Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.
> Flutter Web is for web apps, not web sites
When you want to draw this distinction: most web apps will still suffer heavily for many users if they use Flutter. To begin with, few web apps don’t use text, scrolling, or form fields. Games are almost the only thing that may not suffer, or only barely suffer. But beyond that: well, that’s what they say its purpose is, but at least two of the three times I’ve encountered Flutter in the wild on the web, it was inappropriate, and frustrating; regular DOM should certainly have been used. (The third, I’ve forgotten what it was. It was probably similarly inappropriate.)
Skia is not the bottleneck. The web platform is. Scrolling is limited on two counts: ① what browsers expose in events is insufficient to match the native implementation (which varies by platform) in scrolling amounts, overscroll behaviour, and related things; and ② the browser is a compositor, and your code will never get access to that layer, because it’s way too deep in performance-, security- and implementation-detail–land, so you’ll always be stuck at least sometimes at least one frame behind “native”, and janky.
Could you be more specific with what the browsers aren't exposing properly? Because in my experience, targeting WebGL+WebAssembly is pretty much exactly the same as targeting OpenGL+GLFW. I use my own renderer made with bare OpenGL + C++ though, not Flutter. All the things you have mentioned (scroll amount, overscroll behavior) are under the control of the GUI library and don't have much to do with what the browser exposes. The compositing of the whole scene is done by the gui library itself
As a concrete demo, try out https://flutter.github.io/samples/web/material_3_demo/.
I use Firefox, Sway, Linux, laptop with precise touchpad.
Normally, I get smooth scrolling at such-and-such a rate of pixels-per-centimetre, with momentum so-and-so, and since comparatively recently, particular overscroll behaviour.
On that site, I get janky scrolling at a somewhat slower rate, with no momentum, and no overscroll. (… and scrolling leftwards in the carousel triggers go-back-a-page rather than scrolling left, so you need to scroll right a little first to “unstick” it, but I believe this is something Flutter could have worked around.) It’s painful. Very painful.
It’s not possible to fix this within the scope of browser mouse events. They’re just the wrong primitive. The consequence is that you can only get native scroll behaviour if you use an actual scrolling area. Which you could do, with mild compromise to the pure-canvas approach, just an invisible one and watch what happens with it, rather than paying attention to scroll events. And that’s pretty much the approach you need to use to get good results: compromise on pure-canvas, and do bits and pieces with actual DOM. For scrolling. For links. For images. For text. For inputs. Oh… huh, look at that, we actually just want real DOM stuff everywhere. Fancy that.
Now you might not immediately get such a bad experience for scrolling: I seem to recall hearing that Safari on macOS basically implements inertia before sending the events, and sends the events with inertia applied. That solves some problems, but causes others.
Actually, I meant two distinct things by “overscroll behaviour”:
① Does it let you scroll past 100% a little and then pull it back, as is increasingly normal, or show some indicator that you’ve reached the end, like Android has historically done, or just do nothing, like all computers historically did?
② Scroll chaining, the CSS overscroll-behavior property, to do with nesting scrolling areas. And note that different platforms behave differently. If you do pure-canvas rendering, you’re stuck: the browser has some of the details needed (and is unlikely to ever tell them: they’re involved implementation detail that varies by platform), and you have some of the details needed, and you can’t really collaborate, it’s just not a good mixture.
When I speak of the browser being a compositor, I refer to how scrolling is no longer implemented in a blocking fashion in the UI thread; these days it’s in a different thread, so that it can implement viewport scrolling independently of content rendering, in order to maintain consistent frame rate even in the presence of slow drawing. Also to do various other tricks to avoid missing frames, mostly platform-specific and involved. Web content will never get that power.
Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?
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.
This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately.
When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
I disagree with this so much for two reasons:
1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far.
2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinion, of course. And yet, as a developer, I care about using the right tool for the right task, and no amount of browser engine optimization can change the fact that XML-based markup language is not the right tool for modern performant cross-platforms UIs.
Native doesn’t mean web. I meant just an input as it works everywhere on a platform, input core.
Partially agree on the web sentiment, it just lacks a proper model, both positioning and styling, for what we call apps.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing.
Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.
In fact the input field is one of the few native UI surfaces in the Telegram app.
it's not a native widget. you can type styles on whatsapp which is not possible on native input.
whatsapp is the poster child of this technique btw.
Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within <p>. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know.
So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
Do you have an example of a texting app that doesn't use native input? This just straight up doesn't seem accurate.
> 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 designer resources needed to get there.
https://docs.flutter.dev/ui/widgets/cupertino
> 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.
I’d much prefer they’ve gone with their own design system. People are already used to bespoke ones (web), badly done ones just remind me of scammy sites.
this so much.
but flutter was probably sold internally as a trojan into ios dev experience. the carrot was multiplatform... and to sell it they needed to at least market that it was "true multiplatform" with native look. which is ironic since they go out of their way to make it pain to build to both in the same app
> having teams of designers eyeball the native designs
No wonder it's not accurate.
> 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 attempt that Google can squash by putting more resources into Flutter if they feel the pressure.
> 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.
> can squash by putting more resources into Flutter
So success?
This reminds me of io.js, which started as a fork of NodeJS but was eventually merged back upstream
>Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
I agree with you that Flutter has been a boon for cross platform development, but to say it's impossible to tell you're using a Flutter app is a bit of an exaggeration. I have no problem identifying Flutter apps. Not that I care as they often have a genuinely nice UI and are performant.
Is the complete lack of accessibility still the giveaway? Last I looked Flutter was a complete nonstarter for accessibility.
I worked on the GPay flutter rewrite and our standard for accessibility was higher than almost any other app I've seen, and was a significant amount of effort spent on that. What accessibility shortcomings does flutter have?
This may be a silly question, but how do I install the Google Pay app on my iPhone?
I'd like to try it out since it's the first app listed in the Flutter Showcase, people keep mentioning it in this thread, and it probably works as well as a Flutter app can, given that it's first-party from Google.
But when I search for it on the App Store, it's nowhere to be found (or at least not in the first 20 results).
It's only for the Indian market. As Google often does, they released Google Wallet for the US market. But that's not a failure of Flutter itself of course, only internal Google politics.
Google pay was never able to fix the pre-compiled animation rendering issue on iOS where the first transition or animation is always janky and then it gets cached and no longer has jank.
That is quite a non-starter imo
Can you elaborate? What's missing that makes you feel confident saying "complete lack of" despite well-documented accessibility functionality (including testing for accessibility)? [1]
[1] https://docs.flutter.dev/ui/accessibility-and-internationali...
How do you know this isn't the toupee fallacy?
You spotted a few correctly so you assume you always spot correctly - but there might be more you miss.
https://rationalwiki.org/wiki/Toupee_fallacyhttps://rational...
The setting screen is the tell. I've yet to see a Flutter app that looks like a traditional iOS setting screen.
How do you do that? I just opened my phone, and the last app I used was a food delivery app. How can I figure out if it's a Flutter app or a native one?
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.
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 totally different from those of UIKit/SwiftUI and interact with gestures differently. The Cupertino theme is a poor facsimile of UIKit and lands squarely in the uncanny valley, which is arguably worse than Material Design. Flutter on iOS also tends to hitch where UIKit/SwiftUI don’t.
There's likely things we missed but we'd love to find examples you might have. We try to be scientific as much as we can https://github.com/flutter/flutter/pull/122275 [coincidentally a community contribution from someone who didn't have to fork :)]
Disclaimer: used to work on some of these animations
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.
There are obvious tells an app is non-native. One of the easiest is to view the settings screen. Setting screens on native apps usually all look the same. I haven't seen one Flutter app that has replicated it.
You can install FlutterShark, it lists all Flutter apps on your device
Haha. Oh, most people know! They might not be knowing it’s Flutter to be specific but they sure know it’s some hybrid/non-native crap.
I recently started using Ente migrating from Authy and goodness it feels and looks awful. I wish 2FAS had a desktop app. There was a native alternative that allows exporting codes. (This is not against Ente devs. I am sure they are a small team bringing out a FOSS product. This is just my preference)
the responsiveness and consistency is fine. ente just have weird design choices but that's a matter of taste
Do you just assume that Flutter is the same as typical other "hybrid/non-native" crap?
I can’t imagine using Flutter for desktop development if only because like most newer UI frameworks, it’s mobile focused and doesn’t come with important desktop widgets like tableviews/datagrids and treeviews.
two_dimensional_scrollables is a first-party package by the Flutter team that implements table views and tree views: https://pub.dev/packages/two_dimensional_scrollables
Canonical is contributing to desktop and is using Flutter for a lot of their desktop components now.
Given Canonical's record that is only further reason to stay far away from it.
Canonical is great when they're following established standards, the problem is when they invent in house tech.
There are plenty, though, and they work amazingly well on desktop: https://pub.dev/packages/syncfusion_flutter_datagrid
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.
Tableviews are pretty niche and tree views mostly get used for files, so I'm fine not having either in apps that aren't about managing lots of data.
I like headers and sections more that tables for most things anyway.
Depends on what's being developed, I guess. No tables/trees is probably ok for a lot of lighter end-user sorts of apps but doing without them for many desktop-first apps and utilities would be rough. Desktop file managers, media library apps, and email apps for example would be quite a lot less useful without multi-column tables at the minimum.
I almost never use email on anything but my phone, and Gmail doesn't use a table. They do some tree stuff for the conversation threads, but conversation threads are obnoxious anyway and I have no idea why anyone likes them, they don't reflect face to face conversations well and always create mistakes where someone forgets to reply to all.
I've replaced a lot of tables in my apps with modal dialog UIs, it's nice to have them behave exactly the same on mobile and web, to not have any risk of mistakes due to filling in a box on the wrong row because the label is too far from the box, and it's just generally more pleasant for us non-ADHDers without very good native multthreading support in our minds.
Android style UI is all about encapsulation and reducing the mental context window to the bare minimum, and it really makes a lot of desktop stuff look pretty clunky and confusing by comparison.
VS Code would definitely suffer a lot without the sidebar tree view though, and it does seem like a lot of people prefer the more open instant access to everything that a table provides, rather than clicking through dialogs.
This is something I have a difficult time agreeing on. I expect a certain level of information density and configurability in desktop UIs, which shoehorned mobile-style UIs don't do well to provide. Deep modality is also a peeve; on desktop there's often no benefit to burying things in mulitple layers of modals — within reason, the most important things should never be more than one click away and great consideration should be put into putting upwards of 2 clicks between the user and their destination.
That said, I do think it's fine to have a simplified mobile-ish UI as an option, but it shouldn't come at the cost of more classical desktop style layouts for those who can leverage them well.
As a sidenote, this is part of why apps like the mac version of Apple Mail and Thunderbird have a considerable number of hardcore adherents, particularly among power users.
There's a number of users who can really make great use of the power user tools, but adding multiple UI options can greatly increase work, because a fully modal workflow might need a completely different frontend, and some apps are meant for the mass market.
Degrading the experience for the majority just to make things better for the power users doesn't seem like it's always the best plan unless you're specifically targeting power users.
In the extreme case, UI for power users can result in production databases being destroyed, or someone getting served food allergens because the menu system made it easy to assign wrong items to wrong customers, or someone's entire family photo collection getting deleted by a single command.
What are some examples of good 'impossible to tell' UIs built with flutter on desktop or web?
My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them.
A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of abstraction you put on top of that hackish foundation, you are still running it in the program (browser) designed to show text. So you can select buttons, navigation controls, images, sound players, etc. And it feels very native to web users.
But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. Sure, you can "opt-out" with recent CSS controls for selection, but it's again, a hack - the default choice of "everything is selectable" is made by default for you by the browser. What does it even mean - select button widget? Why would you enable this complicated selection functionality for your UI that allows users to select navigation buttons with a blue selection box? Of course, if your app needs this functionality - you can add it. But otherwise, it would be labeled as a very stupid UI choice. Yet, feels native to web.
Another example is zooming. Because UI apps written in web stack can't completely hide the fact that what they are doing is essentially trying to morph text primitives into complicated UI widgets (makes sense for 2024, right?), and the browser is essentially a text viewer, everything is zoomable and feels "native" to be able to zoom a web app. And yet, this rarely works as intended. In any other UI framework, making zoom functionality requires thinking about what and how you want to zoom and why. OS text size preferences are well handled by flutter, but sometimes you do want to add your own zoom functionality. In web though you just blindly zoom everything, often blowing off the layouts and that feels very "native" to web.
My point is, that I don't think UI frameworks should try to match the nativeness of web, especially when they start targeting the wasm platform. These couple of decades of proliferation of web frameworks built on top of HTML/JS/CSS should just wane in history as a dark period of software engineering.
> But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider.
You say "insanely stupid", I say wonderful.
Everything you apparently hate about the web is what makes it good for users. Content is primary, and my user agent can resize it, restyle it, copy it, extract it, link it, read it to a blind person...
If you want to make a binary blob app, just make that. Stop trying to break the web.
> You say "insanely stupid", I say wonderful.
Yes, that's the most common response. I've heard stories about "how wonderful when you can select everything" multiple times, and that's, of course, just shows how human rationalization works.
And yet, this "feature" or "UI choice" is not even a choice. It's just a byproduct of using the wrong stack for the task. Like, nobody ever sat and asked, "Do we want our apps to have everything as a selectable feature?" before shipping this "feature". It just happened, and then, of course, millions of humans, having no actual choice over it, naturally rationalized that as a "wonderful" feature.
It didn't "just happen" the early architects of the web designed a system to make it easy to share and remix content and subsequent generations of companies and their UX designers have so far failed to fully claw back user freedoms.
Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.
Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...
Those are some of the most niche use cases I've ever heard, and that is stretching it even on HN, much less anyone in the non HN bubble. Things like screen readers work just fine on non browser apps that don't have selectable text, for example.
Copy-pasting UI elements to ask for help on support forums is absolutely not a niche use case. You're asking for a world of even more terrible screenshots in support channels. Truly cursed software.
Who exactly is copy pasting UI elements? I have literally never heard of anyone copy pasting UI elements of all things over just taking a screenshot of the page, so please provide an actual example. And even if you were able to copy and paste, how would you preserve the layout of the UI since only text is selectable?
Selecting everything is what every UI toolkit should support. In the 90s it may have been acceptable to show an error MessageBox with a non-selectable message but it shouldn't be acceptable today. What needs to be selectable is defined by users not developers and the union set of those requirements is "everything".
Browser zoom also only ever breaks if you are fighting the Browser's layout engine instead of embracing that. Just don't do that and it works fine.
Of course most web "apps" shouldn't be apps in the first place but if they must be "apps" at least stop reimplementing a crappier version fo the native browser functionality.
What are some examples of good 'impossible to tell' UIs built with flutter on mobile?
Bolt [1] and Bolt Food [2], for example. One of the apps is built with Flutter, another one is native. Can you tell which one and explain how you noticed it?
https://www.youtube.com/watch?v=3X8COSnscbQ [1]
https://www.youtube.com/watch?v=VOgrdt5WQcI [2]
LOL Bolt is a React Native shop.
Just Google "bolt react native" they have jobs and articles about their usage but also any library inspector will tell you that.
Nope, one of them is Flutter (I know team PM personally). Which one?
Dude. They're even on the React Native showcase page.
I don't know what to say but you're massively mistaken.
Uber use React Native too BTW. Lots of other big tech companies also, I don't know of any that use Flutter in a big way. Just some toe dipping
Bolt Food is on the showcase page, not Bolt itself, which would be odd not to add both if indeed they were both RN, so seems like one is RN and the other is not, which is basically what the above commenter was saying initially. None of what you said really invalidates their point, because again if you search for RN jobs for Bolt, why would you not also assume it's for the one on the showcase, ie, Bolt Food? Bolt is the company name after all, not just the app name.
You were right. After your comment, I went back to my friend at Bolt and asked again. Bolt Food is on RN, Bolt is native. The conversation we had about Flutter back then was about his other project and not Bolt Food.
Google Wallet & Google Classroom
> Google Wallet
Do you mean https://wallet.google/, which says “only available on Android”?
Your parent comment asked for “on desktop or web”.
Flutter is really not some big revelation and it's always shocking to me how it's evangelists act like it's the game changer no one else has noticed.
It's just not that good?
Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea.
What's a native UI?
The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)? And then Android? Ironic then that Google is the one behind Flutter.
The concept of native outside of MacOS/iOS is pretty busted at this point. At best it just means something non-web.
Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits.
Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using.
Is this too much fragmentation for users on those platforms to realistically expect commercial software to support them natively? Yes, of course, but that doesn't mean there is any confusion about what it would mean to do so.
Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.
> Linux is a kernel project,
Is that useful pedantry? From context, you really think that's my confusion here? I didn't include *BSD either, but it isn't any different for the relative handful of people using that for a desktop system.
> Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there.
Except for Microsoft's numerous attempts to supplant it and the fact that the base OS doesn't even use it consistently for their own system. Microsoft's own File Explorer and Settings app that only had to live along with Control Panel for a decade, was that not native? They aren't "Win32". If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API. Nobody casually calls it USER though, and the bulk of people still targeting it do so through .NET these days via Winforms.
If native just means provided by the vendors base system, ok, but then if there are 10 different forms of it, other than the distribution issue there isn't some great intrinsic benefit over just targeting Qt or Flutter. Especially when someone like Microsoft can't settle on a consistent design language through the years.
> If you insist on pedantry, you should know Win32 isn't a GUI toolkit either, it's an anachronistic term for the Windows API.
I don’t think it is “anachronistic” - as far as I am aware it is still the official name. And I don’t think calling it the “Windows API” is right, since Win32 is just one of the APIs that Windows offers. If I’m calling CreateFile, I’m using the Win32 API, but if I’m calling NtCreateFile, I’m not using the Win32 API, I’m using the native NT API instead. If I set the subsystem as NT instead of Win32 in my executable’s PE header, calls to native NT APIs such as NtCreateFile will still work fine, attempts to use Win32 subsystem APIs won’t. And there are other APIs Windows has which aren’t (strictly speaking) part of either the native NT API or the Win32 API - COM and the many APIs built on top of it, .Net, WinRT, DirectX, etc.
But you are right that Win32 isn’t a GUI toolkit. It contains a rather basic and old-fashioned GUI toolkit (USER), but it contains a lot of non-GUI APIs too. I’m reasonably familiar with those parts of the Win32 API used by services and console mode apps, but if you asked me to write a Win32 GUI event loop I’d be asking ChatGPT to remind me how, because while I’ve read tutorials I’ve never actually attempted it.
The name itself is anachronistic, what does the 32 stand for? You call CreateFile with 64-bit pointers, it was still considered Win32 (until they officially changed it).
But take it up with Microsoft: https://learn.microsoft.com/en-us/windows/win32/apiindex/win...
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
The URL still has win32 in it, lol.
Though this naming goes back nearly 2 decades https://learn.microsoft.com/en-us/previous-versions/tn-archi...
The API provided by ntdll is semi-officially called the "Native" API and much of it is subsumed into the Windows API. The PE subsystem names you are referring to are IMAGE_SUBSYSTEM_NATIVE and IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat consistent. Microsoft officially refers to that API as Native System Services in the documentation for the DDK.
https://learn.microsoft.com/en-us/sysinternals/resources/ins...
Microsoft’s docs are a self-contradictory tangled incomplete and sometimes even downright erroneous mess, I wouldn’t put too much stock in what they say.
If I say “CreateFile is the Win32 API analog of NtCreateFile in the NT native API”, everyone experienced with low-level Windows development will know what I am talking about. If I started talking about “Native System Services”, I’m not sure as many would.
Similarly, the distinction between APIs which are easy to call from C code (and simpler FFI frameworks from scripting languages, e.g. libffi) and COM/Automation/.Net/WinRT APIs which are a lot more difficult to use from C (as opposed to C++), and which require more advanced FFI support, is still important in Windows development (or at least some parts of it.) And in practice the term “Win32 API” is often defined to exclude those higher-level harder-to-call-from-plain-old-C APIs.
It goes back to the original design of Windows NT, where you had a primary environment subsystem (Win32), secondary environment subsystems (OS/2 and POSIX), and integral subsystems (local security authority, session manager, etc). The primary environment subsystem is still called Win32, and the Win32 API is its public API. (It also has private APIs, most notably the CSRSS LPC interface, but that’s unstable from version to version.). As I said “Windows API” is insufficiently specific because (especially nowadays) Windows has lots of other APIs. WinRT and Win32 are both Windows APIs but very different. WinRT is largely built on top of Win32, but some documented WinRT APIs are built on undocumented Win32 APIs, leaving WinRT the only officially supported API to access certain functions.
Microsoft intentionally didn’t rename Win32 to Win64 when they added 64-bit support because it is 99% the same API just with some highly regular changes (mainly widening pointers). By contrast, Win32 was a much more radical change to Win16 - the Win16 API directly incorporates notions of segmented memory, which it uses to implement movable memory blocks (rather similar to Classic MacOS, albeit that did it in a 24/32-bit flat memory model rather than a 16-bit segmented one). Microsoft could have done a more straightforward port of Win16 to 32-bit x86, e.g. using a 32-bit segmented memory model instead of 32-bit flat memory, keeping movable memory; but (thankfully) they didn’t. It would have made it a lot harder to move to 64-bit or non-x86 platforms.
>Is that useful pedantry? From context, you really think that's my confusion here?
I don't know what could possibly confuse anyone about the role of GTK and QT in the Linux ecosystem.
GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough options and I used the former for years. GTK itself isn't even a well defined target.
And GTK3 apps of which there are plenty do not appear native in a modern GNOME desktop much more so than a decent Qt app does.
The thing is that people in the real world talk about Linux support for an app, as in Desktop Linux support, and the only common denominator there for years was basically X11. I have heard exactly no one ever ask, oh when is that app going to be available for KDE or GNOME. For example, to take something recent here, do the people writing the Zed editor promise a particular DE support - no it's available for "Linux."
As to earlier mentioning distros - for a GUI app, there’s more pain from intra-distro variation than inter-distro, both across configurations and supported versions.
Now the big thing, the even bigger thing is probably native Wayland vs X11, but no one says, oh vendor will you please bring your app to KDE or GNOME, specifically. 99% of the time you are happy if you get anything at all. So the concept of native on Linux (Desktop Linux) just isn't something usually worth discussing.
> What is native on Linux? Gtk, Qt, Motif (lol)?
Linux is not something that encompasses a GUI, so this is a misguided way to frame the underlying concern. One might as well ask what toolkit is native on smartphones, or what language is natively spoken by humans.
We should instead ask what is native on Plasma, or on GNOME.
"Oh, bother. That would mean I have to think of four things instead of three."
Well, yes, Pooh. But the things that make them different are the things that make them, them.
Ok but this is in response to this:
"Just build native UIs. I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea."
The stupid idea is thinking that building native UIs is targeting a clean, non-moving target and implying it is not astronomically harder than doing something cross platform that is between mediocre and good enough for everybody.
Whenever someone says “just do native” it always turns out they have a cockamamie definition of native, otherwise they would realize the gravity and general unreasonableness of what they were asking.
On a side note, what’s a major* reasonably complex app that isn’t a music player or an IRC client, or something with a simple shell around a canvas like a browser, that targets both Plasma and GNOME natively.
* And whether anyone likes it or not, few people care (as revealed by $$, not bitching on a forum). Blame electron, the web, but even Microsoft cannot even define and maintain a native LnF for their core operating system. As I alluded to, the only small community that cares are those on MacOS and iOS, where there is a HIG that more than 2 people have read and give a shit about, and there is a small market of people that value well integrated Mac apps that will actually spend money. Targeting Win USER32 +/- XAML, Qt, GTK, and AppKit is costly and thankless when you probably could have just used Qt, JavaFX, or Flutter, etc.
I would consider both GTK and Qt native on Linux.
So that means one has to target both GTK and Qt to be native on Linux. Fat chance of that on anything but yet another music player or other relatively trivial UI app.
In any event, that still doesn't answer what it means to be "native"? And my point is I think most definitions are dumb or useless.
If I'm running a GTK desktop, Qt apps are generally not "native" no matter how much theme fuckery one tries. Native can also speak to other common UI affordances and design guidelines, and there sure as hell is nothing like there is in the MacOS world for linux. Some core GNOME and KDE desktop apps maybe, but overall there isn't much adopted standardization in Linux world.
90% of the work I get done involving a GUI outside a browser on Linux usually involves Java, whether it be Intellij, ghidra, etc. Maybe I'll pick up blender from time to time. Audacity, there's a good one, targeting (for now) a cross-platform toolkit that pretends you can have your cake and eat it too - wxWidgets never fooled anyone - they sure as hell don't look native on MacOS, and they invariably look much closer to what they riffed off of, a 90s MFC app. (And wxWidgets wraps GTK and AppKit, so is it native? If so, native is meaningless IMHO. If not, why not?)
> So that means one has to target both GTK and Qt to be native on Linux.
Doesn't it mean that you can target _either_ and be considered native?
Also, I'm not sure I buy the claim that of "GTK and Qt are native" in the first place. I'd say either that there is no native UI, or if I must call something native, it's the toolkit the desktop environment uses. And yes, that does mean that there is no "Linux nativeness" like there is Windows nativeness, as every DE is different. And rightly so, because one could in principle write a different DE over the Windows kernel, whose UI would behave differently.
> Doesn't it mean that you can target _either_ and be considered native?
Well, no because I was agreeing with you, if you're going to grudgingly accept your definition for native, the toolkit the desktop environment uses, that means you would have to target both Qt and GTK unless you want to draw a line in the sand and say fuck it to one of GNOME or KDE as assume they don't exist. Sorry GNUStep. And this is nothing to say of GTK 2-4.
I agree that just saying GTK or Qt are native in a vacuum outside of DE is a completely useless definition, and even taking DE into account is a tenuous one.
As for Windows, what GUI toolkit does the desktop environment there use? That's a trick question.
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.
> Both Qt and GTK have facilities for integrating into each other’s desktop environments
Neither Qt nor GTK are desktop environments and Qt certainly isn’t defined by a dominant desktop environment - KDE isn’t even what pays their bills.
You’re still proving my point. The common denominator here (on Linux) is just X11/Wayland. If it works out “pretty okay”, then score one for a cross platform toolkit. Still no idea what über alles “native” means.
Let’s go back to the original comment I responded to… why should I not just continue with the Qt “stupid” “hobbyhorse”
WinUI3 doesn’t kill WinForms… WPF, WinUI, WinForms all exist together
You missed the sarcasm. If all can exist together, which one is the “native” one? If the answer is all of the above, then the consistency argument for native doesn’t hold much water.
> Just build native UIs
Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?
Yeah I do see why they don't want to do it and I see it as a critical failure of risk management.
If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs.
The risk analysis of building against supposed cross platform "solutions" just doesn't work out. Why do we keep trying to do it?
The idea of cross platform UI is frankly "f*cked from the jump" and should never have been a goal. I think it's only a goal because it's intellectually satisfying, not because it's really desirable.
> and I see it as a critical failure of risk management.
I also want to live in the world where risk management is the only variable that determines how CTOs and devs choose the stack for the software.
Back in the real world however you have canonical for years now who have made flutter the default for all native linux desktop development.
I think your anecdotes are a bit out of date and irrelevant.
People much better informed than you looked at this problem in a lot more detail in real life situations and came to very different conclusions.
> you have canonical for years now who have made flutter the default for all native linux desktop development
And yet, I can't think of a single app I depend on for anything on Linux that relies on it.
How'd Snap go for Canonical?
Cool, none of that is remotely relevant to what we are talking about here.
Your anecdotes are dated and you should think about updating them so you don’t talk so confidently on things you don’t actually seem to know much about.
I mean that sincerely not as some internet gotcha there’s just no need to sit there defending a position that is based on old info just for the sake of it.
As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.
Qt either Widgets or Quick definitely does not use a web renderer
"WinUI3 hasn't even officially launched"
? It officially launched with version 1.0 and it's now on 1.6?
I can't really speak to the differences but
> At this time, there are two generations of WinUI: WinUI 2 for UWP and WinUI in the Windows App SDK (WinUI 3).
> https://learn.microsoft.com/en-us/windows/apps/winui/
Hence why OP was specifically talking about WinUI 3 (which is indeed at version 1.6.1 as of right now).
Windows App SDK seems to be at 1.6.1, which includes WinUI 3.
It's really something I know nothing about so I googled WinUI3 and the 3 first results are microsoft website and github, and the next two are "is winui3 dead ?" and "Oh winui3 is really" dead. So it doesn't inspire confidence :)
I suppose it was incorrect of me to say it hasn't "officially" launched then. But one would certainly seem to get that impression, considering it's missing major features (data table support?) isn't anywhere near feature parity with either WPF or winforms, and doesn't even have a visual editor (which should be table stakes for a modern 1.0 release from a company as large as Microsoft).
> I don't know why cross platform UI has been such a hobbyhorse for so many for so long: it's a stupid idea.
You suggest to build and maintain same logic in at least C#/C++ + Swift + Kotlin + JS + C++ and you ask why crossplatform UI is a popular idea?
> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
I know I use exactly one and it sucks. It’s all janky and weird compared to the rest of the system.
> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.
Electron-based apps are also everywhere and they are through and through bad and a step backward. I would take caution to not do appeals to authority. I would extend this assertion over any javascript-on-a-webview-based GUI framework. Awful concept from start to finish.
The fact that you failed to give any specifics to support your superlatives leads to suspect that the comparison with Electron is well suited.
Not OP, but what makes Flutter good IMO is drawing directly to native canvas, a very good hot reload implementation and AOT compilation.
There are three ways cross-platform UI frameworks draw UI. 1) wrap platform controls, 2) use webview or 3) use low-level graphics API.
Option 1 has to design controls to cater for the lowest common denominator. And there is a higher chance that an OS update might break things that in options 2 or 3. Being based on wildly different APIs (for each platform) increases complexity of creating and maintaining custom controls.
Option 2 has to render UI through a high-level declarative language made for documents.
Option 3 uses same APIs as native UI frameworks use. It's basically alternative implementation of an UI framework. Downside is that it has it's own look and feel, which is mostly an issue, if native UI framework is more polished.
Flutter, being option 3, is more similar to a game engine, than to Electron. Low-level graphic APIs maintain good backwards compatibility, so OS updates don't affect the framework much. Less maintenance is needed.
Good hot reload makes use of XML unnecessary and allows to declare UI in an actual, more powerful programming language. Overall, this removes another layer of complexity. (MS take a hint)
AOT compilation enables fast startup times and less pauses. Which is good as end users are opening and closing applications all the time.
You are right, sheer popularity is not the argument for the quality of the framework. I wrote those two sentences separately for different purposes (the second was more of a reflection of other comments in the thread. I should've put it in a separate paragraph or elaborated more.
Which flutter apps do I likely use?
The only one I often use is Immich. It's laggy and at times freezes completely for a second.
I don't think that's the developers fault though, I don't have that issue with any other android app.
I recently started Immich and also say the awful lag. But apparently this is due to a slow "album sync" running often on the main thread. Not the fault of flutter.
I don't know how syncing my 200 albums can be that slow but they are a big project to move it off of the main thread.
According to its web site, eBay, New York Times, Square, American Airlines.
Specifically eBay Motors, which is a standalone app.
https://flutter.dev/showcase/ebay
I'm suspicious of those because it shows an ebay logo but then shows an app I've never heard of or used...is this the same for all the other logos? Where does NYT use flutter?
Flutter web publicly launched with a NYT prototype https://verygood.ventures/success-stories/new-york-times
I recognize that as the NYT Games (formerly NYT Crossword) app.
It has some very annoying non-native behavior, like bringing up the text selection/highlight menu in inappropriate places (in a word puzzle with no selectable text).
Or the non-native keyboard ... honestly made me stop using it altogether
Yeah that's really annoying too.
I've solved thousands of daily crossword puzzles in that app.
I don’t believe NYT has used Flutter for some years.
Listing eBay and NYT seems pretty misleading when it's actually eBay Motors and NYT Games and not their primary apps.
I can't tell if the same applies to Square or American Airlines but I would not be surprised.
Hacki a nice frontent for havkernews
After using Typescript and React, building a front-end with Flutter is boring, as are other Google frameworks (Angular, GWT).
Maybe if you've never worked with TS/React and more generally HTML/JS/CSS, then it may be OK for some use-cases.
> Flutter is the best thing that happened to UI development since Qt.
Which programming languages have a good developer experience with flutter beside dart ?
None, Flutter is dart only.
it's possible to tell
Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do.
Shepherding these patches is no fun when you have your own changes to work on that are more important to the team.
We did something similar, by creating an external fork where changes could be tried out by the community, without necessarily being accepted into the internal version.
I think a fork could work if there was enough external momentum, but even 20 people working full time would actually be pretty good for an open source project. How many developers will this fork attract? The fork would need to attract other businesses who can put people on it.
One downside is that the code isn't tested against google3. Sometimes you find actual bugs that way.
Edit: reading more closely, the complaint doesn't seem to be that patches weren't reviewed, but rather that bug reports weren't investigated. That's definitely something outside developers could do more of, and seems a lot easier than forking?
The main Flutter GitHub repo does have infrastructure to run PR against all Google internal tests (which as you say, does find real bugs). https://imgur.com/a/Ih2oQIS
disclaimer: my team runs said infrastructure
Does that automatically run against every PR? What mitigations did you have to put in place for Google security to allow running untrusted code from PRs on internal CI?
Semi-automatically. Googlers have to review it.
Also known as “manually”.
What is google3?
Here is a paper describing google3 https://research.google/pubs/why-google-stores-billions-of-l..., which includes the policy that “To prevent dependency conflicts, as outlined earlier, it is important that only one version of an open source project be available at any given time.” More documentation on The One Version Rule for third_party: https://opensource.google/documentation/reference/thirdparty.... This rule may make it more difficult to upgrade a third_party library frequently since the maintainer of the third_party library has to test all the uses of the library from all teams, rather than each team deciding when to upgrade.
I used to maintain the internal (single) version of numpy and scipy and honestly I think the one-version rule was awesome. It greatly reduced noise and churn. It meant far less breakage, and it was easy to find and fix all the breaking tests when I was updating to a new version. I guess the only downside is sometimes an older version of numpy would prevent deepmind from making some sort of ML advance until I upgraded to get some new feature they wanted.
Google's monorepo of closed source code.
Google's internal monorepo.
Couldn't flutter work as public-first that then gets vendored into third_party? Or is that literally the fork strategy you are talking about that I'm too dense to understand?
Yeah, that's what I meant. Public-first is good in some ways, but it means some bugs might be discovered rather late.
> when you have your own changes to work on that are more important to the team.
That part is the killer. Important to the Google Flutter team != important to the wider Flutter community.
Or maybe it’s not important to the community either? Sometimes, a bug is pretty obscure and only important to the person who filed it. People will get annoyed if they aren’t investigated, though.
It’s good to be a little skeptical when people claim to speak for the community just because they’re part of the community. Often it’s not so.
Yeah, this seems to be a common theme with Google's open source projects. Bazel feels very similar in many points.
It obviously wouldn't exist if not for Google putting resources towards it, but Google's (and google3's needs) are so significantly prioritized that it hurts the community. E.g. due to the low allocation of resources and extensive usage of rules_proto and bazel-skylib inside google3, they are completely ossified and the community has given up contributing to them and instead created either forks or contribution-friendly wrappers.
i avoid contributing to flutter because it feels like a google soon to be abandoned project.
hacks like not accepting tabs in any tools and using space indentation wrong on top of it. tools ignore parameters like port numbers just so it works better for Android studio very specific use case while bringing pain to any ci pipeline, etc.
> 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. I've certainly worked on things with much worse ratios than that.
> one has to critically assess why a team that loves external contributions has only managed to merge contributions from 1,500 developers over a span of nearly a decade.
External contributions from 1500 developers over a decade is a lot. That is an unusually high number, not a low one, and backs up Flutter's claim to love external contributions.
The fact that this person thinks that they can just magically conjure up dozens of volunteer PR reviewers is wild. Everything about this post makes it pretty clear that they don't have the slightest clue of the scope of what they're trying to do. This feels like one of the standard examples of an ex-bigco person setting off on their own with no understanding how just how much the bigco did in the background to facilitate their job.
Our user base is of a similar order of magnitude, with around 70 developers. It doesn’t seem like a large number, indeed! A small minority frequently contacts support, suggests features, etc., while the majority simply uses the product.
50 people is a pretty huge team at Google to start with, there’s teams of <5 that support weird bits of core infrastructure that serve billions of users an hour.
Exaggeration?
Billions per HOUR seems quite a stretch there..
I believe it. I've never worked at Google, but I was the engineer for SMS/Voice registration at WhatsApp, ocassionally with one other engineer (I believe the team was 3 when I left, not sure if it grew); I think there were two engineers doing my job for Facebook; although they had a little bit more scope, since there were more kinds of SMS they sent. That doesn't have a huge request rate, but it is super important.
Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.
Exactly, there’s really like three dozen or so people globally who really should never be in the same room at the same time as the risk is too great they get hit by the same asteroid.
I’d put “person who makes sure WhatsApp verification codes work” on that list.
> I’d put “person who makes sure WhatsApp verification codes work” on that list.
Thanks! That part of my job really wasn't too hard though, once I got things in order; but it was the easiest part of my job to describe. Just a lot of debugging from sparse data, and trying to get things to work a smidge better, because smidges here and there add up. It really helped to have a great customer service team that bubbled up usable information from users.
Debugging things from sparse data gets you involved in a lot of different systems though... That and I told people I worked at an ISP in the before times, so guess who got to fight with sendmail, and guess who got to own our Domain accounts and DNS accounts and guess who got to get x.509 certificates, and who had to fight with Google Apps to make mandatory 2fa usable, etc. Basically everything without a person and server adjacent got me. :P
Anyway, I've moved on (replaced by a team of three on the SMS stuff amyway, much better bus factor) and am semi-retired and no longer in any critical path, which is a lot less stress.
World population is 8.2 billion. Assume that 1/3 are asleep at any given time, leaving 5.5 billion awake. It’s not a huge stretch to imagine 20% of them (1.1 billion) using core Google services during peak times.
I don't find it hard to believe. I am not at Google but I work on a product with 200 million MAU, in a core team that serves requests to every single one of those users and there are 6 of us.
Nope.
Link to proof?
Out of curiosity, what proof are you expecting to get? An internal Google usage report and a list of developer names that work on core infra?
Can’t, but not sure why that’s hard to believe?
Because billions of people or their devices aren't even online every hour.
Unless you're discussing background processes on google's side
Push notifications need to connect to that many devices every hour easily
You may not get a notification every hour, but the phone still have to connect to Google APIs to check to know that.
You can say same thing about say location services, every phone if powered and connected to the internet would ping more than one an hour, more than billion devices are definitely online at any give time, not just Android phones, also every android TV, tablet, watch, and the hundreds if not thousands of other devices running GMS on top of AOSP .
There are probably few other APIs in GMS that would ping at least once an hour each device that is powered on, perhaps things like NTP for timing alerts or Emergency Alerts etc.
You may consider them "Background Services" , most of them however have some foreground UI if they need to, and users will notice if they don't work
There are roughly 5 billion smartphone users now, those devices are almost always on and sending background data somewhere. By volume, more of that data guess to Google than anybody else, on the order of hundreds of network requests per device, per hour.
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.
WhatsApp had less than 50 engineers (or was it employees total?) when Facebook bought them out, and they had millions of users.
What a bizarre comparison, WhatsApp engineers didn't have to review code for millions of users.
What a bizarre statement. cURL is basically maintained by a single person, and nearly the whole world uses it.
> cURL is basically maintained by a single person
Suppose Flutter may be an order or two magnitude more complex than cURL.
Absolutely, yes! Then make it two or three people, maybe 10 and there are still n-times too many people working on flutter compared to cURL.
Which boils down to: Number of devs vs. people using something is a very bad metric. Even number of supported devices won't work good in this case (I assume cURL runs basically everywhere).
I think it's very difficult to estimate complexity, and then make a statement about "how many people are enough" is even more difficult. Some environments are harder and more complex, some are just very heterogen and some are both. Sometimes it's the organizational overhead, maybe even something else.
Two orders of magnitude would be 100, not 10.
I'm not sure that something being 100x more complex means you need 100x more people.
plus they said an "order or two" which would be 10-100x so ...
glib then?
How is it bizarre to compare the impact of a low number of engineers affecting millions of people. In the case of WhatsApp it was 35 engineers affecting 350 million people.
https://news.ycombinator.com/item?id=39447564
The support needs of developers is generally higher than those of a messaging user. How often have you had to contact the support of a messaging app you use? Now think about how often you create a Github issue or PR for an open source repo.
WhatsApp has a very narrow use case and feature set to support. Flutter is a multi-platform framework for developing apps like WhatsApp. It seems like a apples and oranges here.
What about Python? They had 34 core developers in 2017 [0]. Python is used by millions of devs. They have to support a multitude of platforms as well.
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
[0] https://pythondev.readthedocs.io/core_devs.html
As core languages, the scope of both Python and Go is fairly well defined.
to be fair, Python's performance has lagged far behind comparable languages (e.g. JS) for at least a decade. maybe more devs could give it the V8 treatment?
V8 is a matter of investment of billions in expertise and time.
I’m not sure what you mean by this but Python can be very performant when you want it to be. That is to say, when you build computation heavy parts in C (or Zig), and remember to avoid the various performance pitfalls like not using generators when you didn’t want to load all those millions of elements into your memory.
What sets professional Python aside from most other programming languages is that everyone who uses it knows that it’s terrible and how to deal with that. Which will sometimes be replacing parts (or all) or it.
To say that it’s inherently less performant than JS is frankly silly though.
Here's one source on Python very obviously not matching Node.js's perf on a simple microbenchmark: https://jott.live/markdown/nodejs_vs_python_
CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector. CPython is way, way simpler than V8, but it's consequently slower. It's just the consequence of Google putting centuries of developer-years into an engine.
You can't just claim Python is fast because Python's C libraries are fast. Those libraries are fast despite Python. Torch is extremely fast, but it's fast from C and Lua too. There's valid reasons to want to compute in your programming language. Python is, ironically, probably popular because its slow speed encouraged users to write blazing fast C libraries rather than even try writing native Python, vs. settling for middling performance as in Java or .NET.
I shouldn't have to get out my hammer and tongs when NumPy doesn't implement the operator I need. Why can't Python be fast like Julia?
I fail to see how Python 3.8.2 could in anyway be relevant in 2024.
Relevant or not, python 3.13 shows the same thing:
Python 3.13.0: 799.6559143066406 ms
Node 18.20.4: 59.34080000221729 ms
So, basically: Python is performant when you don't use Python?
Yes. Is that so weird? JS is also performant when you don’t use JS considering you’re running it on C or Rust and are likely using the FFI if you’re doing any form of computation heavy work.
Yes, it's very weird. When I write JavaScript, I expect it to run reasonably fast because of the JIT - and it does. I've never felt the need to use FFI, and libraries that use it generally do so because they want to interact with pre-existing C or C++ code, not because it's the only way to get decent performance.
Keep in mind performant just means that it works in an effective or expected way. It doesn’t necessarily say much about performance.
Yes. Python is performant when all the performance-sensitive code is written as extension code.
I'm comparing the impact. Small tens of developers, affecting millions of people.
Sure and 1 guy built flappy birds played by tens of millions. The complexity is a completely different ball game IMO.
Flappy Bird was taken off the store by its author, if you take WhatsApp off the app store, that would be a completely different reaction to Flappy Bird.
Millions of people can be affected in different ways.
The power of Erlang.
Since Instagram had only 13 employees when Facebook bought them for $1 billion, does that mean:
Modified Erlang. Genuine one didn't scale.
The whole point of running an opensource OS/vm/runtime/etc is that you can tweak things here and there when you need them.
Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.
Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.
We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.
Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.
How so? Is there anything on what changes they made to Erlang/BEAM?
Process groups, some solid performance tweaks to ETS and Mnesia, etc. It all got upstreamed or became redundant eventually. Rick Reed gave a couple talks about it around a decade ago if you can track down recordings.
Thank you
BSD too.
I generally agree, the fact that the project relies on Google's internal steering is the much bigger factor in this to me.
There is no guarantee these 50 devs can actually focus on Flutter, instead they might get looped in in the internal race to AI products.
I mean we do actually have many years of real life experience at this point of how they perform in the real world.
I’ve never actually come across a better maintained project personally. It is incredibly thoughtfully developed with a high level of attention to detail who have successfully shipped a huge number of major improvements in ways that made sense.
There is a premise in the post that implies Flutter is poorly maintained and that’s just not a commonly held belief by the community at all.
As I hinted to in another comment the particular person behind this is a bit of an oddball and I think there may be other reasons that drove this decision in the first place in addition to the ones he gave in the post which for the record I’m sure there are some things he wishes were prioritised differently but this fork seems kind of very “him” rather than a popular position that people were begging for.
these are also 50 google devs (that may or may not be at the company anymore) by this estimate. They could have just said there were critical tickets not addressed by Gooogle and their PR's ignored, and would have gotten a much more sympathetic response.
Even though they didn't say, that was my assumption. Why would they bother, otherwise? And that's not wrong.
Yeah, the person primarily behind this is a bit of an oddball in my experience who had a somewhat contentious relationship with the team which he himself was once a part of and it’s not clear if he left or was asked to leave.
But reading that post I couldn’t help but shake the feeling that there might be other non disclosed reasons for the fork because some of the ones he did give as you pointed out didn’t make a lot of sense to me either.
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.
You’re most likely confusing Flutter with the Python team which was laid off but the work moved to a team in Germany. The Flutter team has not been laid off to my knowledge.
It struck me that they estimate that the number of qualified contributors is 1000, but the number _so far_ is 1500.
They're slightly different things (as the post notes, the bigger number includes copy editors), but still…
We got around 3m with seven guys, so yeah, and we don't even have on-call rotation / schedule, even though emergencies do happen from time to time. They think 1:1000 ratio is too big as well? That's crazy.
Are you comparing a developer platform to consumer software there? Dev platforms have radically different support costs to regular SaaS or mobile apps. Developers are really support intense.
> Developers are really support intense.
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?
No, generally developers prefer to request help or work around an issue than dive in and fix it. The activation energy for contributing to an upstream project is high and very few do it.
Developers are support intense because dev tools and platforms get used in a bazillion ways and combinations you can't predict. It's not like a nice consumer app where the user can only press a limited combination of buttons, and test coverage can be quite exhaustive. GUI toolkits are especially a bottomless pit of edge cases and bugs because they have tens of thousands of API methods, enormous numbers of features, they can all be used in combination, they have to run on multiple platforms usually and those platforms also have bugs etc. The support costs of a GUI toolkit are basically unbounded.
no, if I'm using your platform, it's because I really don't want to deal with the stinking pile of abstraction below that. so on the contrary, I would see it as a negative if the abstraction was that leaky.
As someone reliant on Flutter, it is likely better to rip off the band-aid now than wait for a slow, prolonged decline. That being said, whilst I am at least somewhat comforted that the person taking charge is someone who was involved with the Flutter team at Google in the past, rather than a random, overenthusiastic person, I have a few crucial criticisms on this post that make me skeptical.
For one, I'd recommend adding a newsletter field to the website/blog, simply so those who may not want to test or participate right away can stay in the loop. More importantly though, the two links asking for reviewers and leads just link to a private Eggs account, which, even before someone decided it was a good idea to just make content appear in an unsorted manner (random post from 2023, then 2021, then 2024, then 2020, ...), has never been an ideal approach for such projects in my opinion. I honestly thought I had clicked on the wrong links when two eggs profiles appeared in new tabs.
Forcing potential devs to create a third-party account on a social media site, then send in DMs is likely not the best way to get such a major project of the ground and having public repos or at least a contact form set up would go a long way, especially since that also makes it easier to enforce some ruleset for applications.
Additionally, consider listing what changes have been implemented in Flock at this stage. As it stands, it appears impossible to easily tell what one can expect without diving into the changes [0] one-by-one.
Still, wishing you the best as Flutters development and approach to both what goes into which branch, as well as keeping up-to-date with UI elements in target OSs has been leaving a lot to be desired to say the least. I still feel that, despite all shortcomings, for certain applications and workflows, Flutter/Dart remains the best, and it would be a shame to see it unmaintained.
[0] https://github.com/flutter/flutter/compare/master...Flutter-...
Flutter Founder here. If you ever have any concerns re: Flutter, please don't ever hesitate to reach out. eric@shorebird.dev
> Flutter Founder here.
Flutter was a company acquired ala Firebase? Always thought it was a project (like Golang) incubated by/for/at Google.
No Eric founded Flutter at Google. However, Google had previously acquired another company called Flutter, and they had that domain lying around, and decided to use it. That's what I understood, at least.
Gotcha. To use "Founder" then seems like a weird choice? I guess, I must catch up to the changing meanings of words used in SV.
The canonical way to say this inside Google would be closer to "I created the Flutter project and launched it externally" instead of "founded"
founder is a word that exists outside the context of SV and has never exclusively been the domain of startups.
Guess you're right. Establishing a "Flutter org" counts. Though, I've never seen folks in this space (Bjarne Stroustrup or Anders Heljsberg for example) say they're the "Founder" of XYZ language / framework.
https://dictionary.cambridge.org/dictionary/english/founder (n)
Correct.
Are you by any chance also a famous poker player? ;-)
I've nothing to add to the conversation, but I jump on this oportinity to tell you that i like the content you've made with Adam Barth on yt very much, have a great day :)
> flutterfoundation.dev
It's not Flutter by own admission, it's very likely not backed by a foundation, and I highly doubt that Google consented to its "Flutter" trademark used for such a foundation.
Good chance that Google legal won't be happy and ask the website to be taken down. https://docs.flutter.dev/brand
Should've gotten flockfoundation
or idgaflock.com
> 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.
Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It's getting a bit long in the tooth, but I feel like 'the mythical man month' should still be required reading for software devs. More devs != better.
> Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It depends on an org's priorities and what gets put on someone's reviews.
During one of the years when I worked on Windows Mobile (before Windows Phone!) we had an objective handed down from on high that we were to spend so many hours a week on customer support forums helping people out.
Well, for that year, customers all around the web got great support right from engineers! I got to paste lots of positive feedback from end users in to my yearly review, and I felt great about it!
If Google cared about supporting Flutter as an Open Source project, they'd make the health of the open source project one of the measurements going into employee reviews at the end of the year.
Totally– This was in the early days of open source .net, when it was still called .net core. We had just moved onto GitHub and I don’t think microsoft had quite figured out how to manage that organizationally. There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
Historically when MS was filled with software nerds, the fastest way was to post on an online forum!
Sadly those days seem long gone. It doesn't feel like Microsoft empowers employees to really reach out and help customers anymore.
I do remember responding to those Tier One support contract requests. IMHO that was a better system than what the large tech companies do now, which is basically just ignore customers no matter what.
It really depends on the product. I don't know about .NET, but it's still the case for anything to do with VSCode, for example.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.
———-
Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.
…now if only StackOverflow had that.
WhatsApp once had just 50 engineers with 900M users: https://www.wired.com/2015/09/whatsapp-serves-900-million-us...
As far as I know Telegram has around the same number of engineers even today, handling around the same size userbase.
Today, Telegram serves around 1B users and is run by only 30 engineers: https://www.reddit.com/r/cscareerquestions/comments/1djposn/...
And support is almost non-existent
On par with Google's, then.
That ethos runs through everything the WA team does. I learned a bit about it when I was at fb and I was beyond impressed by how few servers WA used for its core infrastructure. It's a really well engineered product.
What more do you need?
That's still plenty of people if you got a few thousand people at AWS/Azure or in this case Meta's in-house cloud making sure your service is running and scaling as it should.
50 developers can do an awful lot - if they aren’t trapped in a feature factory environment.
The constant pressure to ship new features instead of only widely desired features overtaxes a team quickly.
Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet.
Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
[1] https://en.wikipedia.org/wiki/Linus%27s_law
> Once the project already exists, is largely feature-complete
That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative.
> mostly in the "fixing bugs and small annoyances" phase
I don't know of any UI framework that has had the luxury of ever reaching that phase.
> then Linus's Law [1] takes over.
If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/
This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone.
> if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done".
Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.
I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs.
It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.
Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.
The OP was talking about developers serving the needs of developers, and the ratio involved there. This is different than developers serving the needs of machines (fifty developers to some arbitrary number of machines is not automatically impressive) or developers serving the need of users. One would expect the ratios involved to be different for all three and highly context-specific.
I'm confused .. is this a Google-led fork? Is "Flutter Foundation" a google sponsored foundation? If not, why use "Flutter" trademark? Also, if the fork is called "Flock", why is this called a "Flutter Foundation"?
Google is the „owner“ of flutter, why would they fork their own thing? The post is describing the problem the author has with google.
But they're using the Flutter trademark. It's a fair question. They appear to be using a trademark owned by someone else without permission.
Right, give it a few days and the domain will change.
They kind of did it before with DartAngular. Maybe this is a Red Hat/CentOS division, where Flock is an upstream community edition and Flutter is ... I don't know.
I asked because it is confusing. My assumption would be that if this is an independent organization they couldn't use 'Flutter' because that is a registered trademark of Google, and they would say they are not connected to Google. I'm looking through their website and github repo for any statement that either asserts or denies a connection to Google - and I'm not seeing it.
They estimate there are one million Flutter developers/users. Have I been sleeping under a rock?
Flutter founder here.
When I led the Google team we had pretty good analytics. `flutter` was for a long time opt-out with analytics and would phone home to Google and report usage. We filtered out docker containers and things that looked like CI and saw usage near 1M monthly actives when I left Google a couple years ago. I'm sure it's up since then.
There are 10s of millions of web developers in the world. Doesn't shock me that Flutter could be over 1M monthly (and probably several million annually).
There are just a lot of apps and app devs out there.
Thank you for creating my favorite app framework.
That said, I literally only use Flutter as a hobbyist.
I made a basic web game for a friend, and a small web app that helps me manage my music lyric videos. I ultimately picked Flutter because I find it easier than actually building websites.
Dart is amazing.
But I'm not deploying to millions of users. At most 10 people have seen my Flutter apps.
It's VERY good for creating quick crud apps with Firebase.
Just counting the number of us who have it installed and might of spun up hello world says nothing about it's actual market share.
To be clear, I absolutely love Flutter, but it's still not something I really see job listings for.
Dart is great too BTW.
on behalf of one of the Flutter founders, thank you for the thank yous.
I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
Quick Google shows Dart 10th, right below SQL, right above Kotlin. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
> I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker?
Speechless.
No, I sarcastically thanked him for free-association about the # of job listings he sees for job listings he's not looking for and what that means about the language.
I'm guess I'm capable of being curious and engaging in conversation, beyond sitting in the bleachers grading everyone on my scale that at 100% is "koolaid drinker.", depending on if I feel like the things they're talking about are on Team A or Team B I've identified.
Then again, that perspective would sort of come naturally if I were reading hysterics into every comment I read. "Big fuck you" is textbook catastrophizing.
Absolutely speechless. on behalf of one of the Flutter founders, he made all of them look bad.
I like to just think he's passionate.
My point was you just can't count SDK downloads as developers. Is every CI/CD pipeline a developer ? The founder of Flutter who posted that stat has a startup which is heavily invested in the perception of Flutter being popular.
In the Unity community we aren't afraid to critique Unity and even suggest trying other engines. Of course Unity isn't open source so you don't get articles like this where someone claims it's time to fork.
At the same time, Unity uses C#, so you can take your skills, and even some nuget packages( with a bit of work) elsewhere if you want to switch.
Flutter requires a higher time commitment since I have to learn a language that's exclusive to Flutter. If this ship goes down I can't use Dart with anything else.
Anyway, I think job postings are a much better metric of adoption. I like Flutter, I've used it for 4 years and I want it to succeed. I don't want to go back to react native!
0.58% of jobs?
If you think its not popular until that increases past one of: JS, Python, Java, C#, PHP, C/C++, Ruby, Go, or SQL...I don't really know what to say. :)
Flutter in Kotlin instead of Dart would have killed! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).
> Flutter in Kotlin instead of Dart would have killed!
Killed the framework for good, true. No pattern matching, joke destructuring, static delegation, reliance on Gradle (puke).
I don’t understand how Dart still has bad reputation when it leapfrogged this joke of a language long time ago.
Just seems like personal preferences. I've used languages with extensive pattern matching and don't feel like I'm missing out without them. Don't really see the problem with Gradle or Static Delegation either.
Then you won’t understand what made Flutter “click”. I work with Kotlin, Gradle and Compose on a day to day job and it is absolutely dreadful experience. Sure, it beats working with Java… Java 8.
Thanks for explaining your stance not a whit.
I was genuinely interested in your thoughts, "you wouldn't understand it, but trust me" is deeply unhelpful.
It’s more of a “too hard to translate all the frustrations that you encounter in day to day” rather than “trust me, bro”.
Glad you found it useful.
Yes, I agree, trying to use Kotlin instead of Dart would have killed Flutter.
I've been hearing about Kotlin multiplatform just as long as flutter, and writing Kotlin since 2019.
Kotlin is a horrible daily driver.
I worked on Android for Google at 7 years, and maybe it'd have a better chance if it didn't win internally. As it stands, there's too many organizational boundaries created, and each organization holds itself accountable only within itself, so it's sort of the worst of all worlds, impedance mismatches everywhere, and nobodys fault they exist
I'm always stunned to read wish casting about Kotlin because there's ~0 path to even basic things that change productivity dramatically, like hot reload.
I'm going to be honest.
C# , NodeJS, Python and rarely Java( had a rough year), pay my bills.
Flutter/Dart doesn't. If you know someone hiring a Flutter developer I'm 100% down to interview.
I don't hate Kotlin, it feels like Google's answer to Swift( although Java was never as hard as Objective C). I even built a small project with it.
Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development?
Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev.
Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
> I don't hate Kotlin, it feels like Google's answer to Swift
You have the wrong order: JetBrains created Kotlin[1], and anything Google had to do with it was just adopting their language. Same story for Gradle choosing it over Groovy
1: https://github.com/JetBrains/kotlin
> Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development?
Google doesn’t promote anything. There are two competing teams with their own agendas. Flutter’s bills are mostly paid by internal usage, as far as I know. Android is mainly focused on Android part of Compose.
Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
> Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev. Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
>I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
I'm not exactly senior to senior, but I hopped from mid level hobbyist Unity dev to professional Unity dev , to mid level .net dev. I have a very specific niche though.
I'm very comfortable with my career.
>Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
Android Studio is free ? Are they really making that much money off users using Kotlin outside of Android Studio ?
Android Studio is subsidized by Google and works pretty much only Android. The moment you have to work something more, e.g. some Web stuff you need to pay for IntelliJ Ultimate as it’s only IDE that supports Kotlin.
They even have Ktor (Kotlin web framework) plugin available only in Ultimate. For any non-trivial Kotlin development you need to have Ultimate.
> you need to pay for IntelliJ Ultimate as it’s only IDE that supports Kotlin.
That is so stunningly false that I am pretty sure I'm feeding the trolls: https://github.com/JetBrains/intellij-community/blob/idea/24... (Apache 2)
Right. Good luck developing Kotlin multiplatform, Ktor, Spring, anything web related or native with Intellij community.
Only for the crowd, I need point out that no one's arguing there's more Dart jobs than C#.
Re: multiple frameworks, I worked at Google and would argue I know as much as anyone does exactly what happened there, so I can't agree it's weird, per se. Handwaving, I'd say that's because the situation seems more 'certain' or 'settled' to me, for good reasons, but ones not worth getting into.
There's absolutely tons of threads to unpack in your comment, I wish we were in person.
Speaking generally, based on observation you gravitated most towards discussing qualities of a job one might or might not get:
I essentially left my job at Google for no paycheck, partially because Google x Koyaanisqatsi, partially because I just couldn't imagine having to go back to write Kotlin and/or Java day to day and being criticized either way. That being said, it's deflating seeing Flutter job listings after getting into this whole industry from iOS dev. Thing with Flutter jobs is there's tons of low priced job seeking competition that are smart as hell.
That's because it is unusually effective in environments where people can't afford a Macbook only for iOS dev, and at this point in its lifecycle, it self selects for people who get experience with new frameworks
Do you personally dislike Java/Kotlin ?
Java just feels like a less refined C# to me, but I'd be fine with it if offered a FAANG job.
I've tried to learn C++ too since I think I'd open up some job opportunities, but it's just too hard for me.
So who won, Kotlin or Flutter ?
From your last paragraph, I take your prefer to work as a Flutter dev all else(pay) being equal?
They want both implementations to compete, and then they deprecate one of them.
Thats an excellent summary, and its fair for you to assume that question has been settled.
(On a serious note), inside Google you tend to get more easily promoted if you launch new products than if you maintain existing products, so it could be tempting for the employees themselves to follow in that direction.
Oh I'm aware (deep foreboding sad voice)
There's no hot reload in Android (kotlin) dev? Wow
yeah, it fascinates me - both Apple and Google started these new UI framework things after Flutter, and both didn't land it, but instead, landed some half-baked thing where individual components can render live in the IDE.
That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resize the window to imitate different screen sizes!", not, oh there's a bug, fix, save, insta-reload, verified fix. No holistic screens, or loading info from a database, or mutating data.
I assume this is an extremely hard problem. I remember trying to get Obj-C hot reload working 15 years ago and it kinda half-worked some of the time. And its not like I can edit the C++ my Flutter app is linking against and get instareload.
But still, it's one of the things thats easy to point out and drives home that these once-a-decade-or-two frameworks started in response to React Native/Flutter aren't addressing the fundamentals of what made them a sea change. Industry is risk averse and we make too many decisions similar to staying on track to launch MacOS 9.110 in 2024, instead of biting the bullet to get OS X done.
> both Apple and Google started these new UI framework things after Flutter, and both didn't land it
For Flutter to have fully landed it, it would take more than just hot reload. I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?
Yeah hot reload's just a one-off example that I think is the simplest way to relate the experience of SwiftUI vs. Compose vs. Flutter, though, the first two are long in the rear view mirror, I've been Flutter only for about a year.
Good question -- I don't think its the wrong question? Maybe? :P Tough to phrase on my end too.
I only feel native speaking in iOS or Flutter, even with the Android experience, forgive me: I guess I'd summarize it as "yeah, you're right. if you're wondering if they're ex. calling CoreGraphics on iOS, no" (well, they do, but for text rendering. Not for a red rectangle)
Generally, Flutter Web is rendering into a WebGL surface using Skia -> WASM (2.2 MB download! modern miracle). macOS, iOS, (done) Android (soon) are switching from Skia to Impeller. I think the thrust of your question is "are they still bundling the render engine?" and the answer is yes.
I find the way you phrased it intriguing, in that, before reading your post I'd say drawing to a Skia canvas is as native as you can get. But I realize now that means I was overindexing on "close to the metal", and its apex not-native to say "gimme the framebuffer and i'll take it from there"
I'm a bit picky with design stuff and I loooooove that Skia's bundled and I can rely on it cross platform
Wait, did you just publicly admit to Google collecting terminal device information without user consent?
Its not the coolest thing but idk if it’s unexpected or scandalous
Are there any statistics on how much of it is used in production?
https://flutter.dev/showcase has a few examples. Flutter is everywhere at this point. TikTok in China (Douyin), PUBG Mobile, MGM Resorts, eBay Motors, Kijiji.com, Grab are a few off the top of my head. And of course a whole bunch of Google apps (GPay, Earth, Classroom, etc.), Toyota cars, LG TVs, Google's own hardware devices, etc. Tonal is probably the app I used most often that's Flutter. Caribou Coffee, Betterment, Norwegian Cruise Lines, NuBank, Realtor.com are other random apps I've used that are Flutter.
small nit: many daily driver apps in China are partially Flutter. But TikTok is not at the present
small nit: douyin is. is it possible you read "TikTok in China (Douyin)" as "TikTok in America"?
Do you have a source for that claim? I'm pretty sure that is incorrect. Bytedance has said they use Flutter but for other projects.[0] Douyin is not mentioned anywhere.
[0] https://flutter.dev/showcase/bytedance
I don't have access to any devices with Douyin on it, so I cannot confirm current usage.
My knowledge of their usage is from discussions with ByteDance some many years ago when I was in charge of the Flutter project at Google. At the time they were using Flutter in 50+ applications (probably most of them internal), including Douyin (TikTok for China) as well as physical hardware kiosks on their campus, web apps, etc.
https://flutter.dev/showcase/bytedance
I just tested Douyin 23.5 from 2022[0] and it does not have the two finger scroll bug.[1] It is of course possible they were carrying their own patch for it all this time but that seems unlikely. I doubt they are using Flutter or if they did it must have been a long time ago.
[0] https://douyin.en.uptodown.com/android/download/87248716
[1] https://github.com/flutter/flutter/issues/11884 - click on the search button in Douyin on the main page and search for something to get to a regular ScrollView. You don't need an account for this.
Flutter two finger scroll "bug" is gone.
I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
I refuse to sideload arbitrary APKs, especially from bytedance. I feel bad because that is irrational, you did, and it'd be really helpful if I did and just did this myself, but, you should install FlutterShark and check: https://play.google.com/store/apps/details?id=com.fluttersha...
>Flutter two finger scroll "bug" is gone.
Why is "bug" in scare quotes here? It was most definitely a bug.
>I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
The actual fix was pretty involved. I doubt a large company like Bytedance would want to carry around extra patches at the gesture level that make the dev cycle more difficult. Having one person carry a patch on their local machine is a different story.
Anyway, the Bytedance blogpost says only 200 devs are using Flutter which would make no sense if it was used in Douyin, and LibChecker[0] returns no results for libflutter.so.
[0] https://github.com/LibChecker/LibChecker
> Why is "bug" in scare quotes here? It was most definitely a bug.
Is it? I thought it was cool, I can't think of why its disruptive to scroll a list faster if you scroll with more fingers.
> I doubt a large company like Bytedance would want to carry around extra patches at the gesture level
I'm a solo endeavour, and I spent ~30 minutes to do exactly this (patch gesture behavior) two days ago. I was stunned how easy it is. But I grew up on versioned closed source dependencies on Apple iOS frameworks that you had to patch the runtime at runtime to fix, so I'm easily wowed.
> 200 devs are using Flutter which would make no sense if it was used in Douyin
Seems reductive: "Only" 200 fulltime, 800 in the company...and we're in a discussion about how 50 maintain _the entire framework_. :)
Yes, via the Flutter founder here: https://news.ycombinator.com/item?id=41975474
If you have an Android phone, get FlutterShark and check which of your installed apps use Flutter. It's a surprising amount actually. For example, I just recently discovered that Supercell uses Flutter for their Supercell-ID flow.
It was 8 out of 86 apps for me (9% of my apps). Including Hacki, the HN client. It's a good variety of apps too, from big billion dollar companies to tiny games I downloaded from F-Droid.
I have a pretty limited understanding of mobile sandboxing, but how does FlutterShark have access to analyse all the apps on my phone?
>android.permission.INTERNET
>android.permission.QUERY_ALL_PACKAGES
>com.google.android.gms.permission.AD_ID
>android.permission.ACCESS_NETWORK_STATE
>android.permission.WAKE_LOCK
>android.permission.FOREGROUND_SERVICE
seems like imo the type of thing you should be prompted for but what do I know
Since the beginning of Android apps could see what other apps were installed on your phone without asking for special permission.
They finally added a permission for it - QUERY_ALL_PACKAGES - in Android 11 (2020). Unfortunately it's one of those stupid permissions like filesystem access where you have to apply for it via a form, and only whitelisted use cases are allowed:
> Permitted uses involve apps that must discover any and all installed apps on the device, for awareness or interoperability purposes may have eligibility for the permission. Permitted uses include device search, antivirus apps, file managers and browsers.
I suppose that situation is slightly better than "anyone can do it for any reason".
FlutterShurk says 3 apps on my phone use Flutter. Device Info (a different app) reports that's 0.2% of all my apps...
I only got one (ASDA), I'm pretty sure it's just a webview though so I'm not sure why they are using Flutter.
Hard to say it is "everywhere". It's probably more popular than any of the other cross platform alternatives though.
There are 25 on mine, so ymmv
Interesting to check, thanks for the tip. I have 6 Flutter apps, half of which I had assumed to be in React Native.
I had about 30 apps. That surprised me.
If there would be 1M flutter devs per year and on average team had 10 devs (rather rare most mobile teams would be smaller except really big apps) and development of app would take ~1 year you would expect minimum 100k new flutter apps in app store every year. That seems highly unlikely.
I suspect there's a lot of larger apps out there which use Flutter for one feature or set of screens but the majority of the app isn't written in Flutter. You could have a team of 100 working on a app where only three of them actually touch flutter on a regular basis, but depending on how exactly you capture analytics all 100 of them may get counted.
I agree. Flutter is a project I like, but the numbers given regarding statistics remind me of this video https://www.youtube.com/watch?v=A-RfHC91Ewc
I‘ve worked for over a year, almost full time, on an internal Flutter app that never saw the light of day (maybe later, if the stars align). Many apps just get their support section revamped with Flutter because there’s no need for that to look fancy; but they‘ll still count against that quota. Many devs prototype their side projects with Flutter, but never release them. Etc
I'm pretty sure many/most professional app developers are in long-term projects, working on the same app(s) year after year. So for those devs the app count never goes up. That's at least my experience -- development work only stops when the app is pulled off the stores for business reasons.
I can share an example from our company’s experience:
- 5 years using Flutter - 31 full-time devs - 3 platforms (iOS, Android, and Web) - 1.3 million monthly active users
Overall, we’re very happy with our decision to use Flutter
Other anecdotal apps: Google Analytics mobile app. BetRivers online sportsbook (one of the largest in the US).
Assuming there are 20 million software engineers in the world writing code professionally, 1 million Flutter developers seems massively optimistic.
Yes. Realistically off by at least a magnitude. There is literally zero chance there's 1 million active developers working on this experimental Google Tech out there.
Flutter has more usage among professional devs than React Native does per stackoverflow survey https://survey.stackoverflow.co/2023/#section-most-popular-t... and statista has similar-enough numbers: https://www.statista.com/statistics/869224/worldwide-softwar...
Seeing as React Native has somewhere around 1 million active developers, Flutter almost certainly does as well.
>working on this experimental Google Tech
while I'd agree with you that 1 million is too high, Flutter certainly is not experimental Google tech. It's widely used in particular internationally. I talked to a ByteDance guy two or three years ago and I think they alone had about 1k Flutter engineers. Nubank, Alibaba, BMW, Ebay use it extensively.
Flawed metric but eyeballing VScode Extension installs, Python 140m, c# 30 mil, Go 15 mil, Flutter 10 mil. It is very, very popular.
100k seems more reasonable.
Just looked via google, and while no one really knows, common estimates of the number of web developers seem higher than that, on the order of 27 million.
Your point may still be valid, but... is 3-5% really that high?
(No dog in this, I'm not doing web development at the moment, although I have and probably will again.)
It's possible that they also count students and amateurs such as me, who only used it in a small project never published. There could be a million I guess, but professional developers are probably a lot less.
I think this is a strong possibility. For example, I don't work in programing and don't intend to ever work in the field. I do it as a hobby. I downloaded flutter, played around with it for a few weekends and decided it wasn't for me. If you go solely by number of downloads I would be counted as a 'flutter developer'
There's 200k weekly downloads of node on npm. A million flutter devs means that there's a comparable amount of node devs to flutter. I'm not sure how else to estimate it, but there's 170k github stars of flutter compared to 100k node, and a roughly equal amount of forks.
The 2024 SO dev survey https://survey.stackoverflow.co/2024/technology/ has flutter at 10% and nodejs at 40%. Github language stats has JS about 10-15x the popularity of dart, but seeing as JS is more than just node it might pan out. https://madnight.github.io/githut/#/pull_requests/2024/1
So I guess looking at the stats 1M flutter devs is not an implausible number on its face.
> There's 200k weekly downloads of node on npm.
I’m pretty sure Node developers usually don’t install Node from npm.
Yeah. For comparison, there are 27 million weekly downloads for React.
I'm not sure what conclusions we can draw from either number.
Does nvm not use npm internally?
Github shows 98% of code is "Shell" on top of that there are also many different package managers that people use: fnm, volta that are build with rust. You can also install nodejs using homebrew.
>Does nvm not use npm internally?
No. It downloads binaries from nodejs.org. There is no "official" canonical means of managing Node versions. It's just a grab bag of community tools like NVM.
I would dare to say that average person who works with Node does not use nvm.
Really? I think it’s even recommended on the node website’s install page
I use Node every day and I've never even heard of the 'node' package before. I think it's very niche.
My experience when I last looked into Flutter was that it was heavily used in India - at least based on who participates in the community online - and much less elsewhere. That's not a value judgement, just might be a factor in why you don't hear much about it if you're not in India.
they're just too close to the problem and overestimating their relevance.
just because someone cloned a repo once or an NPM package was downloaded doesn't mean someone is a flutter dev. I don't know what the best metric would be, but its relevance is definitely overstated
Yeah, people like to count their "downloads" and call that their "users", but it's at least an order of magnitude difference in my experience. Sometimes a 100x difference.
I was wondering the same. How many Android developers are there?!
Wow, I had seen signs that Flutter was something special for years, but hadn't checked in a while.
Some relevant data:
- Over 165K GH stars
- Over 140K subredditers
- Over 500K YouTube subscribers
The 1M estimate is at least ballpark accurate.
https://pldb.io/concepts/flutter.html
Does subscribing to a coffee-tuber automatically make you a barista?
James Hoffman, I presume?
I don’t sub him on YouTube - but I’m not lying when I say everyone I know IRL who does sub his channel has worked as a barista at some point in their lives (…and purchase actual chemical-lab supplies for their coffee brews).
Flutter is truly a piece of great tech with remarkable quality and value. I hope the right path will be found.
I think companies using it for commercial purposes (like what we're doing) should contribute something to the effort to help make sure Flutter not only survives, but flourishes.
Bug bounties, supporting individual developers, supporting efforts and initiatives, professional services, or any other way that helps the project move forward will be great.
> Flutter is truly a piece of great tech with remarkable quality and value.
How does it compare to React Native from user and developer experience perspectives? Are there other competitors?
It's better in most ways, for example, just recently LG decided to rewrite its TV apps from RN to Flutter
https://webostv.developer.lge.com/news/2024-07-15-new-and-su...
> Most of our apps use React. When we first adopted React, we were pleased with the development productivity it provided, but sadly its initial performance was subpar in terms of start-up time, memory consumption, and responsiveness. After significant and complicated optimizations we reached performance benchmarks that were good enough, and yet we desired a new technology that was both fast and simple.
> To our delight, our very first prototype with Flutter easily exceeded our target benchmarks! Without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive and playful to use
Misleading on the comment, LG WebOS is using EnactJS (Framework on top of ReactJS) + Chromium Embedded Browser, not native, just webapp on browser.
But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.
Embedded browser is slower than native app, because extra browser layer than native one.
> But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.
Sure, but you're compiling two radically different languages. JavaScript is dynamically typed (even with TypeScript) and Dart has a sound static type system.
It's much easier to compile Dart to efficient native code than it is JavaScript.
I wonder how it compares now with the latest version of RN that brings out a lot of performance gains induced by the removal of their native bridge, and also faster startup by making lazy loading of modules the default option
Sounds like it might be talking about web React, not RN, also
Not familiar with webOS, but are they talking about React Native specifically or just "web" stack React?
Faster and better in almost every respect we've looked at vs React Native or Electron. We're super happy with this choice we made quite some time ago.
I'm not qualified to give an in depth review/comparison, however.
Edit: we use flutter to build an app which runs on iOS, Android, macOS, Windows and Linux -- the same code base with pretty minor adaptations to desktop vs mobile and different screen sizes.
The experience has so far been fantastic. It's fast, it's relatively light weight, it's performant, it's a pleasure and we couldn't imagine doing it any other way.
We have worked with flutter since 2019; having built internal apps for our staff, public apps for our customers, small utility apps etc- this has been our experience as well. Not only flutter has been rock solid, easy and fast to develop, it has a wide array of libraries. Long may it continue.
I've been working with Flutter for a little over 2 years nonstop. Before I started this project, knowing enough react, I experimented with react native, Expo, also quasar, capacitor, nativescript, and other cross-platform mobile solutions. Flutter/Dart was just nicer to deal with than everything else. I needed to work with C code too, and Flutter made it straightforward with FFI.
The developer experience was great and the Flutter team was very responsive with questions I asked.
For xplat is same concept, compile to native code on multiple target system.
The other xplat framework same as Flutter:
- React Native
- Kotlin Multiplatform
- NET MAUI
- NativeScript
- Slint
Ionic&Capacitor with Angular/React/Vue
NativeScript
> 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
In India Flutter is quite popular. But I also doubt there will be professional 1M flutter devs our there. However if we include students and hobbyists, then definitely there could be a 1M Flutter devs out there.
It's probably within an order of magnitude but it's really just hobbyists, casuals and indies using it.
If you compare it to React Native there probably are more Flutter apps published but if you drill down into the top 1000 on each app store you would be lucky to find more than a few in most countries using Flutter whereas React Native definitely makes up more than 10%, maybe as high as 30% of non-game apps. I know on my phone I have zero Flutter based apps installed and almost 20% use React Native in some way.
Source: I'm an app developer so I keep an eye on these things.
The fork is called "flock" and it's part of "flutter foundation"? It appears they forked Google's confusing branding strategy as well.
wait for similar WordPress drama if google owns 'flutter' trademark.
They do.
Yeah you are right. https://docs.flutter.dev/brand
I expect there will be some communication from Google at some point and the foundation will have to be renamed. It reminds me of OpenTF being renamed to OpenTofu.
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 another perpetual treadmill.
Not to mention it includes a dedicated language, which takes significant effort in its own right.
Add to that, that as a project gets larger and more complicated, it becomes harder to change and tech debt builds up.
It's not surprising to me issues are building up. I've got to wonder if a fork, while it can move forward in one respect, may just be adding more complexity in a project that already has too much.
It wouldn't surprise me if Flutter's unmanaged complexity is exponential, in which case quadrupling the number of dedicated engineers won't move the needle a lot.
> 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.
Key statement: "As Flock ships important bug fixes and features, the Flutter team can then choose to add those to Flutter, on their schedule. "
I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.
Flutter Founder here. I'm very pro open-source, and pro taking-action, so hopefully good things will come out of it. I think this particular author is mostly stirring up a bunch of noise and does not represent a significant chunk of the community, but we'll see. :shrug:
> ...the Flutter team is in maintenance mode for 3 of its 6 supported platforms. Desktop is quite possibly the greatest untapped value for Flutter, but it's now mostly stagnant.
Can you make any comment on this? Is it accurate?
I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.
Canonical gave an update on Flutter desktop last weekend at their Ubuntu Summit: https://events.canonical.com/event/51/contributions/533/
It’s a bit unsettling to see Ubuntu demo stuff on Windows (I know that Flutter looks and behaves the same on Linux, but still).
> :shrug:
Is it time for HN to finally support Slack-style emojis?
I'd want them to fix this nonsense first https://news.ycombinator.com/formatdoc
I'm almost positive you, personally, could implement support for those emoji short codes via Violentmonkey
Agree, if it pans out this way in reality of course. That'd be splendid!
NodeJS went through something similar. It was tightly controlled by a single company (Joyent) who were juggling too many balls, and progress went slowly. Community people did a fork (io.js) which shipped improvements faster, but they did so in a careful non-shitty way. This made lots of people switch to io.js, so that eventually NodeJS merged with io.js (iirc they just renamed the latest io.js "NodeJS").
I don't know of any other instances of community forks of company-controlled OSS that did something similar though. If this is just one guy who made a blog post, like a sibling comment suggests it might be, then it might not pan out this way.
> needs of the community
The constant question of big tech OSS is who is it for/why does it exist? Did they make this because they think it's a useful tool internally, or are they trying to build a platform for external developers? If they built it because it's internally useful, then it's probably open-sourced for cultural reasons (the people working on it are used to being in open source communities and want to share what they're working on).
Unless something is specifically being made as a platform for external developers (Android and Firebase come to mind), the level of support you'll get is at the whims of the team's current product leadership and budget. Both of those things change over time - a product manager can always say "let's focus on internal developers" and put the external community in maintenance mode. Based on the article's mention of desktop support being deprioritized, this might have happened on Flutter.
Big tech funds things that would be really hard to pull off with just volunteers, but big tech projects can also be victims to the capriciousness of corporate politics and budgeting.
Wouldn't it be good to launch with at least a few bugs fixes? The launch is a bit thin, just mirroring, nothing to offer?
> 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.
I doubt google have even 50 flutter devs in their team. You can easily estimate by checking github pulse:
https://github.com/flutter/flutter/pulse/monthly
https://github.com/flutter/engine/pulse/monthly
Also take into account inflated commits by CI bots: engine-flutter-autoroll, skia-flutter-autoroll, auto-submit[bot], fluttergithubbot, flutter-pub-roller-bot
https://ln.hixie.ch/?start=1714717681&count=1 is a sensible estimation
Actions (commits) speak better than words for me - flutter managers like (kevmoo) that are responsible for PR what gonna say? Probably you not gonna hear form them "Sorry we had layoffs and unfortunately our team is to small to handle all issues for now" Same with previous google employees that are still invested in flutter ecosystems by launching commercial products around it even if not at google anymore.
This sounds bitter and misinformed. Check automotive grade Linux and check GitHub for flutter embedders. Flutter being deployed all over the place. It’s impressive. The tooling and DX is excellent.
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.
The thing I worry about is that its going to be really hard to get a large number of PR reviewers up to speed for this fork, while also maintaining reasonable quality.
I think it's going to be difficult to maintain a separate fork without diverging from Flutter, because over time, the fork will accumulate bug fixes and features that the Google version will not accept (by definition, since the proposal is to be more accepting of PRs). How are we supposed to go back to the Google version of Flutter as the fork diverges more and more from the original?
Or is the proposal that we should stick with the fork, and the fork will over time pull in the new features and PRs from the Google version? But how will that work after say 12 to 24 months of divergence? There's going to be a hodgepodge of new features and bug fixes on the fork, and then Google will release a new version of Flutter with a whole set of new capabilities ... and we'll be stuck having to choose. Or we'll have to do a really hairy merge between the Fork and the new version from Google.
This just seems scary to me. Especially since for any given team, there's usually one ... or maybe two things we want to patch into the Flutter tree. Its easier for us to just apply those fixes onto a new version of Google's flutter tree than it would be to patch a whole community's worth of bug fixes and features onto the new Google tree.
I think the preferable course of action is that the community should work with Google to see if there's a way to improve the speed of PR reviews.
I'm worried about the chaos that forking could cause in this community that doesn't really have a huge number of contributors yet.
> 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.
I believe he means "a founder who uses Flutter". Poor wording, but I don't think it was intentional.
Thank you.
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.
I meant to say, "Founder using Flutter here".
Nice. Tesla founder here BTW.
I like Flutter, and Dart for that matter, but I lost inspiration to keep going because it felt like I was learning something deeply that will be dead in a few years. Why not just learn Swift instead? Or if it must be cross-platform, Qt?
Is this the right stance to take? I just want to pick a desktop app development stack that has some staying power, and isn’t riddled with quirks.
I guess flutter web is the "hook" because it promises a "true" cross platform stack, even though imo it is still very lacking. On the other hand, QT on mobile (iOS, android) is also a bit weird, and comes with lots of restrictions and gotchas. And it basically does not have any support for web apps (except for some super recent, very experimental wasm platform support, that would probably be even worse than the "app on canvas" experience that flutter web offers)
Who's "We're" ?
I only see a single name?
Is this just some dude with a blog?
1 developer supporting 1 developer, better ratio than Google
Very sad article to read. I just expect the original Flutter will now die a slow death. I applaud the effort and hope they will be able to find a monetization model that works to support the development. There have been similar projects based on technologies that Microsoft has killed (Silverlight -> OpenSilver and various .NET-based cross-platform technologies) that serve their customers well. Unfortunately, none of them are in any way "mainstream" like Flutter is today.
> There have been similar projects based on technologies that Microsoft has killed
Isn't flutter from google?
Yes, it is. I was just thinking about what happened when other companies did something similar.
Didn't Google suddenly kill GWT, which is a bit like flutter?
No, it transitioned it to others after signaling it would for well over a year, so i don't think you could call it sudden:
"In 2011 with the introduction of the Dart programming language, Google stated that GWT would continue to be supported for the foreseeable future while also hinting at a possible rapprochement between the two Google approaches to structured web programming. However, they also mentioned that several of the engineers previously working on GWT are now working on Dart.[6]
In 2012 at their annual I/O conference, Google announced that GWT would be transformed from a Google project to a fully open-sourced project.[7]
In July 2013, Google posted on its GWT blog that the transformation to an open-source project was completed.[8]"
Google funded/helped for some number of years after that.
It still is going, afaik, with gwt 2.11 being released in january, 2024.
https://www.gwtproject.org/
Yes. But the other technologies mentioned were from Microsoft.
>Very sad article to read. I just expect the original Flutter will now die a slow death.
I find it odd that you would think this fork would even have an impact on Flutter or its roadmap.
That might be the wrong way to interpret this. It actually validates interest in the framework. This change personally excited me and injects some change into the ecosystem that could result in a better future.
To still use flutter in the name when your project is called flock seems beyond misleading.
Better than using a distinct name for a mostly-identical project or effort (looking at you, MariaDB).
"MariaDB is named after Widenius' younger daughter, Maria. (MySQL is named after his other daughter, My.)" (Wikipedia)
https://en.wikipedia.org/wiki/Michael_Widenius
(No insult intended to Maria or Michael, it's a lovely name in itself.)
Are you suggesting that they should have used a name that might lead Oracle to sue them instead of being clearly differentiated?
Also, there is an existing messaging and collaboration tool called Flock: https://www.flock.com/
My onions, let me show you them: https://en.wikipedia.org/wiki/Flock_(web_browser)
And a fantastic way to get sued out of existence by a rich corporation.
FWIW, the only realistic legal action right now is a cease and desist letter.
Which will be responded to swiftly with no lawsuits or damages exchanged.
Who is 'we'? I'm not familiar enough with this ecosystem to understand. Is this one person or a set of existing contributors, or something else?
Exactly my thoughts. How anybody would take it seriously if the people behind are not known, is beyond me. Anyway I left flutter a long time ago exactly because the mentioned problems - ridiculously slow response time fixing bugs, like auto fill want working.
Our industry has few innovative ideas in past decades ranging from small to large. Rust, React, Tailwind, Typescript, Nix come to mind. All these did things differently enough to seem weird at first.
Flutter is hands down the best DX product with a beautiful language. It is modern Qt and destined for great success given it doesn't get sent to Google's graveyard.
As for the fork, I don't see anyway it not significantly diverging from upstream because bug fixes might involve refactoring which would make difficult to pull in upstream changes.
While surfing around the various repos, I was reminded about the bad taste I got from the last time someone sung the praises of Flutter/Dart; this thing is firmly in the "Android SDK-ish" school of thought: download a shitload of prebuilt binaries from storage.googleapis.com, dontyouworryaboutit
Would you recommend a different distribution mechanism? The Apple binaries are all signed (in accordance with Apple policies), and the team has historically invested significantly in supply chain security. e.g. (a now 2 year old article)
https://opensource.googleblog.com/2022/09/flutter-slsa-progr...
I'm in the camp of "if I can't build it, then it's not open source" so https://github.com/Homebrew/homebrew-core/blob/d314f3ebba9e7... is a good start, but there is no .../f/flutter.rb although there is https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flutt... but I haven't been soaking in the AUR ecosystem long enough to be able to port it to Homebrew
All those words to say that if there was a .github/workflow/release.yml showing the steps required to cook a release artifact that would be the best(?) documentation since it is kind of like a Dockerfile in that it's computer executable but mostly human readable
I don't mean to poo-poo all the "supply chain security" effort, but you have to recognize that right now it's "trust me, bro" since https://github.com/Homebrew/homebrew-cask/blob/27c351ccb59fb... does check the sha256, and good for them, but gives me no way to trace back to any file in https://github.com/flutter/flutter/tree/3.24.4
Of all the different dev stacks I've used Flutter has given me the fewest issues across updates. I've never run `flutter upgrade` and then had serious trouble getting an existing project to run.
Compared to js, react & react native, python, ruby etc I've just never hit the same bitrot so they're doing something right.
Absolutely true. It’s so much easier to upgrade dependencies and if it works / most likely works. We had a small UI regression in a very large app and that hadn’t been touched in 1 year.
Almost everything these days is installed like that.
Flutterfoundation.dev
Was created for flock?
This seems less of a fork and more of an attempted annex
> That's 50 people serving the needs of 1,000,000.
The SQLite developers must find this rationale hilarious.
> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
Are there no escape hatches?
> Your team doesn't know how to work on the Flutter framework
The only escape hatch I can think of is to either have the team learn how to work on Flutter itself or hire someone who can.
Xplat FWs are just technical debt to prove a concept. Once you find critical mass the first order of business should be converting to native so you can remove that entire layer of additional complexity. Similar to paying down student debt to minimize how much interest you wind up paying on them after getting a good job.
IMO this should be the natural order if you size use it at all, not the emergency case.
> that entire layer of additional complexity
There are different ways to think about complexity. In terms of the code that's being executed, certainly using a cross-platform framework is likely to result in more complex code as the final output. However, for apps that do not need to use a lot of native features, cross-platform frameworks can significantly reduce the amount of code that needs to be written.
It also means that the entire mobile team can become experts in one framework rather than needing iOS and Android folks. That said, it's certainly still helpful to have deep platform knowledge to debug/optimize in certain situations. But I think the point where using a cross-platform framework stops making sense is going to be very different for different applications.
> That's 50 people serving the needs of 1,000,000. [...] 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.
Ever heard of e.g. curl? Because a billion users use your software does not mean that you have to talk to a billion users.
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
Does curl have any semblance of customer support?
> The team can't fix the bug without information from me, and it's been too long for me to provide information to the team.
Ugh. I feel like developers should already know this, but I guess not: If at all possible, please, please, please include a solid reproduction case when reporting bugs. That way you don’t have to remember anything about it. (This is also pretty much the only way you can be certain that the problem isn't actually due to your own error/misunderstanding.)
> What do you do if the team won't work on that bug for 2 years?
This is reminiscent of how the Qt Company operates. Qt is super buggy and their bug tracker is full of unresolved bugs from years ago. However, the difference is that if you're a premium user you can pay for premium support to get someone to fix your bug.
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 usable for more would be an initiative I would applaud.
I work on Dart.
Programming language popularity is hard. The network effects are absolutely massive. 99% of all programming languages are a rounding error away from having zero users. To start to compete with any of the big entrenched languages seems to require either:
1. An extremely easy migration story so the language can leverage ("parasitize"?) the existing ecosystem of another alread popular language. That's C++ for C, Kotlin for Java, TypeScript for JS, etc. This is definitely the easiest path to success.
But it means your language is significantly hampered in its design because of the need to be compatible with the language it's building on. This is why C++ is still failing to be a safe language and is a sprawling mess. It's why Kotlin has type erasure. It's why TypeScript, despite having a fantastically complex type system, is still unsound and can't use types to compile more efficient code.
2. A compelling platform or framework that developers want to be on so bad they'll learn a new language. Rails for Ruby, iOS for Objective-C and Swift. This is the harder path but it means the new language is less shackled to a previous one and can be more innovative.
Dart took the second path. I agree it would be nice if Dart had more pillars shoring up its success than just Flutter and I hope we get there one day. But one successful framework is more than most newer languages have and you have to start somewhere.
I'm obviously biased, but I think Dart is a good general purpose language and would work well for many different domains. But fighting against the network effects is hard and growth takes time.
The Dart community tries to extend itself outside Flutter, there’s Serverpod for backend development for example.
It’s the Dart Team that is focused on Flutter.
C# port of Flutter would be a dream.
Well, I hear that there's a foundation for it, so: new leadership, new rules. I can't tell from the outside how much of Flutter/Flock is deeply tied to Dart versus it just happens to be a bespoke language because 20% Time exists
C# has Maui for mobile and desktop development. And Blazor for fronted.
The community is oriented towards having one framework or library for doing one thing.
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.
Yeah not sure why this is downvoted it is true, a lot of the open source tooling for ios is built in ruby and plenty of people build scripts and cli tools in ruby.
I'd like it the other way around and want to see Flutter APIs for other languages (lets say Kotlin). Personally I feel no desire to learn Dart to use it only for Flutter.
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I'd love to see some examples. I've had my pull request merged in a fairly quick amount of time - less than one release cycle, which is what matters here.
Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller). So it's hard to take this announcement seriously.
> Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller).
For me its so weird they ditched google/skia to develop Impeller in Dart from scratch in the first place. If skia was not ready they could move just 1-2 developers to Skia team to collaborate with them. Now they want to even write their own 3d rendering lib based on Impeller (flutter_gpu, flutter_scene) even thought google has already mature 3d engine in C++ (google/filament). For me from the outside looks like "not envented in our team" syndrome. We are now in funny situation that react native has react-native-skia and react-native-filament and Flutter teams reinvents the wheels.
https://github.com/flutter/engine/blob/main/impeller/docs/fa... discusses the reasoning a bit. There's more of a difference in the approach
Related https://groups.google.com/g/skia-discuss/c/Fzpne-f9gZ4/m/5_I...
Seems like most issues could be solved with new Skia graphite backend
Also related: https://github.com/flutter/flutter/issues/77412 - Hixie's issue that led to Impeller (or one of many issues)
Some related iOS jank issues from that time: https://github.com/flutter/flutter/issues/32170 https://github.com/flutter/flutter/issues/61450
As someone who has slowly been writing Dart/Flutter bindings for Filament[0] over the last couple of years, I agree the internal 3D engine was a bit of a strange choice of priorities.
[0] https://github.com/nmfisher/thermion
The build process for skia and its dependencies is huge. Flutter compiles (on windows) with CMake and Skia uses googles GN tool.
https://skia.org/docs/user/build/
https://gn.googlesource.com/gn
They been building it before and still building and releasing with flutter so it's not like they don't have pipeline for that. And it was distributed compiled so nothing to compile for 3rd party users.
Words are cheap.
Seems like:
- guy wants to add PR more aggressively to a code base than Flutter currently is
- isn’t clear if they have a concept of handling compatibility between fork and original
- why not be a labor organizing entity and work with the flutter team?
Some of the PR that I am aware of that are stale and could be good candidates - are difficult design decisions and stakes need to be put in the group.
It seems ill advised. This is huge amount of work with limited upside and huge downside (adding uncertainty to outsiders looking in) and tons of effort (just in infrastructure maintenance).
Edit: if I were conspiracy oriented I would think it’s to harm community. I would pay this no mind.
Note that I know nothing of the Flutter team/culture and am only answering generally:
>why not be a labor organizing entity and work with the flutter team?
Depends on the maintainers/team. I've definitely seen many a bureaucracy that slows down FOSS to a crawl of bug fixes and feature progression. If you make enough PRs that are ignored for weeks or months, you'll realize this isn't really a team ready for nor interested in a proper FOSS environment and it's instead mostly "that teams code that happens to be readable".
Their official answer seems to suggest as much:
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I guess we'll see. I'm way more of the mentality of "actions speak louder" so I'm not really one to announce my plans until I get something worthwhile off the ground (in this case, a few stale PR's that feel like game changers to the customers). But that's not a mentality modern social media rewards.
There is a comment above that shows the founding former didn’t want to fix tests in his PR. Flutter is massive and it’s critical infrastructure. The tests are critical to up-keep. The tests are probably a majority of the work. Which makes sense for something that has such a large surface area.
I think this is an emotional reaction from someone has never managed a large project. Merging PRs and releasing them isn’t the problem. I hope they understand that.
Flutter is amazing. Web, desktop and mobile that actually work is nearly magical. Yes there are priorities. Yes the desktop isn’t as high priority of web. It does work. Hell. Collect money and fund Hixie or others to prioritize patches community feel should go in. That is constructive and methodical/reproducible.
Forking a massive code base, applying PR and not conforming to the source repo standards (tests whether that is golden or not) - just seems not well thought out.
I think community could fund a well known developer to fix desktop issues and have PR adhere to Flutter standards. It’s a ton of work. But seems like it’s a money/dev/process issue. Not a PR merging exercise.
If someone could do the same with Xamarin/Maui that would be awesome!
It’s going down the same path unfortunately as Flutter did.
Microsoft has de-staffed and deprioritized Xamarin/Maui to a point most of the folks are in Aspire-dotnet and related efforts?
It's such a shame mobile development with C# isn't more viable. I want to make some apps, and I hate JavaScript, but from everything I've read Maui just isn't practical.
Flutter has seen a lot of Xamarin refugees. Even the founder of Xamarin himself is a big Flutter fan:
https://twitter.com/migueldeicaza/status/1778759403451081159
The native approach is quite viable: my MvvmCross-based app has been on both stores since 2018 with almost zero MAUI/Xamarin-related issues, even with hundreds of thousands of installs.
Not gonna lie though: building the UI twice for both iOS and Android feels somewhat masochistic. But in the end, it "just works" with shared View/ViewModel logic on both platforms.
> Imagine that you're the engineering director, or CTO of a company whose next release is blocked by some Flutter bug. What do you do if the team won't work on that bug for 2 years?
Then you fix the bug? If your team can't then pay a consultant who can? Isn't it open source? What did I miss?
I couldn't agree more, """In other words, I believe there are blind spots because Flutter team members don't actually use Flutter.""" Electron creators made atom, the best text editor, and then vscode, And flutter doesn't have a signature app to show that it can be used for serious purposes. Currently, the most famous open source app in the community is appflow.io, I compare the current state of appflow.io to the current state of flutter, even the unfixable bugs. I compare vscode to the JavaScript ecosystem, with both advantages and disadvantages,
> sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
This is what's wrong with companies trying to do OSS. They are literally unable to get over themselves and tap into the one quality that makes OSS so worthwhile: tapping into third parties volunteering their time, creativity, and ideas. The need to tightly control direction and strategy of a project leads to companies putting up walls that make it hard to tap into this.
IMHO, Google made several mistakes with Flutter that stem from their "not invented here syndrome". Effectively they've been competing with their own people on things like Kotlin, Kotlin multiplatform, and now Compose Multiplatform which is emerging as a direct competitor to flutter (does the same things on the same platforms). The obvious move years ago would have been to open up the flutter platform to other languages than Dart (especially Kotlin) and share code across both ecosystems and make the combined solution a better one.
That never happened. Dart is alright but in the end it's just another Java/Kotlin like language. IMHO Kotlin is nicer. But that's just me. Interoperability between Swift and Kotlin native now exists on IOS. Compose works on IOS. But Dart-Kotlin interoperability is not a thing.
This is not some kind of oversight. This is so obvious that it must have been proposed, multiple times, and blocked by Google management for internal political reasons. I have no other explanation. Any technical blocking issues would have been fixable/addressable. They chose not to. And now Flutter is de-prioritized internally and the team reduced in size because Google created another dead end. This is self inflicted failure. It took an outside team from Jetbrains to take Jetpack Compose and turn it into the multi-platform solution it is now becoming.
A foundation with a fork is the right move. Fix the above and great stuff might happen. Google doing things alone isn't working for them. Repeatedly. They need outside help. It's there for the taking. They should not fight this foundation but back it with money and transfer the entire flutter team to it.
With SwiftUI the gains Flutter had (on ios) are diminished. Flutter was way better than ObjC and the nasty layout thing ios apps had before, but today swiftui is really good.
It really makes me wonder how and why Microsoft and Google can't create a cross-platform GUI ecosystem that lasts. Like, they both will have multiple operating systems and platforms such as web and mobile in use at their company and no doubt build a huge amount of bespoke tools. Wouldn't it behoove themselves to create a cross-platform GUI solution that actually works, is maintained, etc.?
I have been looking into building one myself, and for a company the size of Google or Microsoft, the task almost looks trivial. But somehow, they create these huge monstrosities like Flutter and .NET MAUI that crumble under their own weight.
This is especially true for Microsoft who sits upon two of the best languages around in C# and F#. Flutter often has a tough sell because it comes with Dart and vice versa. For Microsoft, is it really that hard to have a three-tiered approach to cross-platform development in that there is a separate, dedicated platform for each of web, mobile, and desktop that share common components (like drawing and animation APIs), architectures, paradigms, and of course languages?
GUI development on desktops is just a complete mess right now. Qt Quick with QML is okay, but it has a huge amount of strange limitations and has a surprising lack of just plug and plug UI components, like charts. Plus, you have to use either C++ or Python. Flutter seems better but also suffers from the lack of professional plug and plug widgets and requires the use of Dart, which is even less ideal. Plus, it requires the support (or lack thereof) from Google. For Microsoft, I could list at least half a dozen cross-platform approaches in a single blink of the eye.
I wish it was just native platforms. Someone needs a faster development and reaching the customers, just use web-views and then bring on native when you have the money, developers, and users. Interacting with non-native apps has consistently been a subpar experience without fail.
I'd rather put my money behind KMP by JetBrains. It has a more streamlines, practical, and consistent future than flutter, react native et al.
| How many Flutter developers exist in the world, today? My guess is that it's on the order of 1,000,000 developers. The real number is probably higher, but one million should be reasonably conservative.
one million flutter developers? that does not make sense to me at all (by orders of magnitude). does anyone know any metric to validate this? i am shocked if it's true.
The data is supposedly there: https://news.ycombinator.com/item?id=41975320
My bank uses flutter (nubank in Brazil) it have a lot of issues and never it worked fine on iPhone mirroring, which is a pain.
How many people are the “we” this blog post talks about? 5 people? 500?
I really hate to be the big downer here but given Google's corporate culture is any of this really a surprise?
Google and failure to support are at this point on par with peanut butter and jelly.
I wouldn't ever trust anything Google cosigns as likely to have much longevity. At this point I just assume we all know better.
This is a welcome fork. Still for me, flutter is not web platform friendly by design(e.g. javascript) and that's the reason I stopped using it and switched to react-native + electronjs(react), they seem more reliable and production ready, plus this approach is totally web friendly.
I had the same thought and ended up learning swift and out had been great.
how are Ubuntu's Flutter integration plans evolving these days?
https://discourse.ubuntu.com/t/refreshing-the-ubuntu-desktop...
Weird, I'd never heard of Flutter (or at least it never registered), but then I'm an infra engineer, so why would I have? But particularly strange is that if you go to flutter.dev, you'll notice you can't find anything about who Flutter is. There's no about page with links to the people behind it, or any indication of what company sponsors it.
Then this flutterfoundation.dev site... weirdly also doesn't say who's behind it. Presumably some outside folks? Maybe just the one person who wrote this blog post? But if it's called "Flutter Foundation" I would expect it to be more officially sanctioned?
Were I in the market for a UI framework, none of this would make me feel very confident.
Well, myself and a few hundred other contributors are behind Flutter. Happy to answer questions.
The flutter.dev page got rewritten to be more "marketing friendly" a few years back. docs.flutter.dev is still maintained by the engineers however.
Regarding who exactly contributes to Flutter, it's all on GitHub, so you can see the actual committers, e.g. https://github.com/flutter/flutter/graphs/contributors https://github.com/flutter/engine/graphs/contributors https://github.com/dart-lang/sdk/graphs/contributors
As for flutterfoundation.dev, it appears to be just Matt? Who used to be employed at Google and reported to me on the Flutter team but is no longer.
> But particularly strange is that if you go to flutter.dev, you'll notice you can't find anything about who Flutter is.
It's on the front page: "A Global Open Source Community. Supported by Google, open to everyone."
“Supported by Google” doesn’t communicate “owned by Google”, and anyway, marketing text in the middle of the page is not particularly telling. I expect a site about some technology to have an About page with some information about who is behind it and who funds it.
Compare https://go.dev/project which explicitly mentions that Google runs the show. The front page makes it clear that Google runs the language’s cloud infra. Plus there’s the Google logo in the footer.
The Flutter page never mentions who runs it. If it’s independent but sponsored by Google, there ought to still be people involved. If it’s owned by Google, it should be clear about it, and not just indirectly mention it.
I had to scroll for fourteen whole seconds on my phone to reach that part of the landing page. Completely invisible if you ask me.
[flagged]
more context on flutter layoffs: https://www.theregister.com/2024/04/29/google_python_flutter...
The layoffs wasn’t Flutter specific, it happened across all orgs.
Is there any way to contact project owners besides X "formerly Twitter"?
I believe this kind of issues happen in Google everywhere. Not sure who to blame for, but it’s definitely a severe crisis Google is facing. Google should spend time fixing it.
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.
Wrong analogy.
It's claiming that people who produce penicillin, are responsible for billions of people who take penicillin.
That's a fair claim.
The most important thing I wish this doesn't cause is to divide the community, but the article addresses this.
I enjoy Flutter a lot, it would be very sad if it got discontinued. An previous employee at Flutter just showcased how powerful the framework can be outside it's main usage. https://www.youtube.com/watch?v=fU6d81MurTQ
> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
they could pay contributor or issue bug bounty..
Based on the article's premise getting that merged is the problem, not fixing code.
right, making maintainers happy is part of that work.
Yeah this isn’t drive-by contributions where you shit out a PR that works for you but makes the test infra fail and you get upset. Ppl need to think big picture.
One big problem, I think, it may not be visible all of the test infrastructure if your outside google. Don’t know. Gerritt is its own world and googlers live there not in GH (it appears).
The main problem in projects like flutter is to always focus on the "new". If you focus on the new without stabilizing the existing basic features, you will accumulate thousands of problems. If the same path is followed in this new project, I think the result will be the same. There is still no clear update on issues opened years ago. and most are pretty basic needs.
> 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!
Given that you could probably make a similar assertion about any popular framework, this doesn't strike me as particularly relevant.
Where's the actual repo for the fork?
It's not linked to anywhere and not listed under the flutter github org...
Who is "we" in all of this?
Not even visible on the github org https://github.com/Flutter-Foundation
> This organization has no public members. You must be a member to see who’s a part of this organization.
> Communication monoculture
This point seems like a callout to a certain discussion and I kind of want to see it
This kind of PC-jargon also makes me want to place a bet that the alleged "monoculture" is some perfectly reasonable insistence on either clarity or basic politeness. Willing to be proved wrong though!
I must be living under the rock. I thought Flutter is prosperous? I only dabbed into Android development as a learning experience so I probably missed something important.
If everything the article says is true, should I switch to Kotlin?
Instead of forking popular libs, someone should think how to improve OSS model. I think it is wrong when projects with 1mln users are not self sustained
Honestly makes sense to me. If Google has proven one thing is that it generally maintains a very tight grip on anything open-source that they ship. Ie. it's extremely hard to contribute upstream. This is fine when it's a package that's critical to good, so they invest a lot into it (for example, Jax). But for stuff that's not quite there, it means fixes will meander for months if not years.
A tangential question: For someone looking to start using React Native (targeting both Android and iOS), is Flutter a viable alternative in 2024 ?
Sounds like Flutter core teams hold contributors to a high standard and the Javascript bros can't deal with real Software Engineering so they're having a party of their own.
In all honesty, good luck. It might be useful if it never breaks compatibility with Flutter.
And so it slowly starts what everyone was expecting from Google projects that don't bring millions back home.
I would love Swift to be forked so it becomes more usable outside of Apple's ecosystem.
Isn't swift already cross platform? https://git.aparoksha.dev/aparoksha/adwaita-swift
Or do you mean the UI Apple uses on top of swift?
What would you change at the language level?
Not at the language level but at library and framework level.
No need to fork Swift to accomplish that.
Anyone else experiencing déjà vu from the days of transitioning from Angular to Angular 2?
No. Angular 2 wasn't a drop-in fork for Angular 1.
Guess Flock is free to use now that Google abandoned their other project named “FLoC”
It would be great to make good flutter support for embedded devices
I highly doubt there are 1,000,000 flutter developers
Hopefully this will turn into an EGCS-like situation.
> We're forking Flutter. This is why.
Cripes I wish people would explain who "we" is. "Flutter Foundation"? Which is "Flock" but not "Flutter"?
What's the Flutter Foundation?
so we cant sent a pr to flutter or what? I always thought flutter is open source
> I always thought flutter is open source
It is, this has nothing to do with that. The argument here is that PRs doesn't get merged easily, which Flock want to ease on
> If every capable Flutter framework contributor in the world regularly contributed to Flutter, that ratio of 1:20,000 would drop to 1:1,000.
LOL. That's how to get any investor to stop taking you seriously. "The global market for x is $$$bn. If we can just get 5% then..."
How do they plan to get anywhere near 100% of potential developers working on it? Most of us here could work on any number of projects, but we don't.
There are 27.4k forks of the flutter repo. This is just yet another one.
Lots of forks are just forks, no changes or they turned stale. Some people fork for no reason, I think it's their way to show appreciation? Idk.
I invested quite a bit of time working in Flutter years ago. The team overpromised and underdelivered. Felt like it was all marketing fluff and I'd been duped.
> 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 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.
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.
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.
Every project is different. Claiming it needs more developers because "it needs to emulate UI of six platforms" as if that justifies a larger team is also fallacious.
I wanted to see the evidence that the community is lacking support and/or flutter is lagging behind competition. That would justify Flock's goal... Otherwise, it sounds a lot like both naivette and a unpublished agenda.
“Flutter team members don't actually use Flutter.” (as per the website).
This could explain a lot.
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
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.
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.
I'm a man who once made medical software for pregnant women. There's no point being dogmatic.
I'm sure all those devs working on fighter jet's software would love to but alas...
> 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.
> I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.
You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.
Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.
Django comes to my mind here. The people behind the framwork had real experience and needs in web publication.
Commenters point is that this is normal
But not necessarily optimal.
It does, however, have bearing. Despite how common the practice may be in the corporate world, developing a framework without any regard to the user experience thereof is pretty suboptimal
Rails has 12 core developers + 5 committers.
https://rubyonrails.org/community
And 17 users.
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/
PHP Foundation has 10 developers and runs a substantial part of the web. 50 developers are definitely the wrong reason to fork flutter.
Not sure this is a good comparison because the PHP Foundation is "relatively" new and afaik there's no strong correlation to "the php development team" besides these people being paid and also work on it. PHP had a 20y history before this foundation, and the main difference is that it was never steered directly by one big company. Zend, yeah, but they had influence, they had neither started the project, nor ever had a long-stretching majority of people in the important positions. (Disclaimer: have not been an active part of the project for a couple years)
Flutter has much bigger scope than PHP Foundation. It's more fair to compare PHP Foundation scope to Dart Lang and Dart SDK. Flutter scope on top of that is Flutter Engine, Flutter Widgets, Flutter Framework, Flutter Packages, Dev Tools (IntelliJ + VSCode). PHP also support desktops/server environments instead of Flutter 6 platform (iOS, Android, Windows, Linux, MacOS, Web). Making crossplatform UI toolkit is the most labor intensive - PHP Foundation is not developing that. PHP had also 2 decades ahead of development.
50 developers would be definitely a good reason to fork. It's way too much. 1, max 2 would be the perfect size.
Python is an engine, flutter is the whole car.
If Flutter is a car, Python is at least four different models of car, plus three models of light truck and one airplane.
The scope of Python's standard library is just enormous.
true, but still - these libraries can be updated independently, one from each other - with a framework, things have to be orchestrated.
In general in PLs this is not true—the standard library is usually very carefully designed and all of its interactions are well-considered—but Python's libraries do seem to be more independently-updated than most.
Even so, isn't that an argument for a smaller, integrated team for the framework, rather than a large one made of ~1000 volunteers? A tightly-knit framework is much more likely to suffer from too many chefs than a disparate collection of library functions.
Between the parallelization problems inherent in a tight framework and the fact that its total surface area is also smaller than a PL that's maintained by about the same number of people, it sure doesn't sound like Flutter's problem lies in developer headcount.
And Python is written in C, unlike Flutter which is written in Dart.
Flutter engine is mostly written in C++.
Other parts are written in Dart like you said.
I doubt that complexity of a language is comparable to that of a widget library. After the text input cell and scrolling window it’s basically dumb geometry/drawing code all along.
It's much harder to to implement a language in a proper way than writing a widget library.
But that hardness comes from the level of knowledge one must have in different fields such as compiler theory, cathegory theory, hardware, beside classical computer science and coding.
To write a widget library you just have to know how to code and have some experience.
That being said, the amount of work for implementing a widget library might be higher, but is less qualified work being done.
I dabbled in computer language theory and compilers and it's hard. I have no issues reading source code for widget and GUI libraries.
The code behind "intelligent", performant and scalable Tree/Greed widget can be quite big and complex and include concurrent/parallel code.
Flutter has its own language (Dart) which I suspect is included in these stats.
The Dart team is separate from the Flutter team, though they do interact as Flutter is now the primary use of Dart and as such, influences what is worked on in the Dart team.
Then Django or Pytorch are cars, too.
Like a Fisker Ocean?
Launched, abandoned. Scammed again.
When are you all gonna learn?
Heh, as long as the ocean does not cause them to burn - https://jalopnik.com/more-than-a-dozen-fisker-karma-hybrids-...
Even whatsapp had about 50 members when they were handling billion users
> Even whatsapp had about 50 members when they were handling billion users
I would add that running a service deployed to N regions is considerably more demanding and work-intensive than working on a releasable software package.
No one working on Flutter is woken up in the middle of the night by a pager because a user was not able to install a package, to then create a call to pull in half a dozen of Flutter engineers.
Seems to me that as projects mature they require less effort too. It's hard to account for that since
Python started in 1989, it's older than Linux and it has a more narrow scope.
Python doesn't have a narrow scope. At least compared to Flutter. It's in so many places, from Linux installers, to medical, aerospace, math,... and finally the web (which is probably what we hear about the most).
But those are modules added on by developers other than the 50 core devs.
The standard library alone has a huge scope which includes a (mediocre) GUI toolkit.
I did not meant to start a pissing contest, I thought the biggest idea was that Flutter isn't 35yo and because of it, it's more likely to drastically change, and in a fast way too.
It includes another scripting language with a GUI toolkit. The Python part is just a shallow wrapper over third party code.
If only some homegrown GUI toolkits were half as good as Tcl/Tk.
Have you seen the python standard library? It ain't JavaScript kiddo
But does python use protobufs and monorepos and <insert google induced fetish here>?
Maybe they have more time to work on the software because of less overhead...
> 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.
https://docs.python.org/3/howto/free-threading-python.html
Besides, it's pure speculation; where's the hard data behind 1.000.000 developers? That's a very large number to be a guess.
Python is really not the same as Flutter. Compare Python to Dart instead.
Yeah... no. The team was recently transferred from the US to Germany, the numbers were estimated around 10 engineers.
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.
"Fear not little Flork..."
https://github.com/flutter/flutter/pulls?q=is%3Apr+author%3A...
- 0 open PRs
- 2 PRs merged, 1 PR closed in the past 4 years
- All PRs reviewed by a member of the Flutter team within 24hrs
- [“If I'm still supposed to write tests, even for this change, then this is probably as far as I take the PR.”](https://github.com/flutter/flutter/pull/128910#issuecomment-...)
- 40+ PRs from 2019
So, disgruntled ex-employee?
I can understand the test frustration on both sides.
* He's being asked to fix tests that were already failing. That can be an enormous task depending on the nature of the failure and the code base.
* The team doesn't want to merge his PR since they don't have a test. The code is presumably working without his PR and understandably they won't change a single byte without seeing tests work.
If existing tests are failing then how are they accepting any PRs at all?
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.
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
Avoid generic tangents. Omit internet tropes.
https://news.ycombinator.com/newsguidelines.html
[dead]
Raise rates.
Really not a fan of the flutter concept. “One codebase?” Ok, so how does that make a great iOS app that takes advantage of the full device? Basically coding to the least common denominator.
Hire a Swift person. Hire an Android person, and build things in a way that gets the most of of the device. Otherwise, what’s the point of an “app” in the first place. Can use a website if “one codebase” is a goal.