We're forking Flutter
flutterfoundation.dev
flutterfoundation.dev
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"
}
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.
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.
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?
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.
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.
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?
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.
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.
? It officially launched with version 1.0 and it's now on 1.6?
> At this time, there are two generations of WinUI: WinUI 2 for UWP and WinUI in the Windows App SDK (WinUI 3).
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.
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?)
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.
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.
> So that means one has to target both GTK and Qt to be native on Linux.
You have reduced the definition of "native" to merely compatible with X11/Wayland (that's the only common denominator). Well now, Tk, FLTK, Swing, and even Wine are all native.
[1]: https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK...
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”
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.
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.
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.
I don't know what could possibly confuse anyone about the role of GTK and QT in the Linux ecosystem.
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.
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.
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...
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.
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.
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?
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.
[1] https://docs.flutter.dev/ui/accessibility-and-internationali...
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).
That is quite a non-starter imo
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...
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.
When using the apps on my iPhone, I just don't see how I could tell the difference.
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.
Disclaimer: used to work on some of these animations
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.
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.
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.
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.
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.
Every time I've ever mentioned it to anyone they really didn't seem to understand or care
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.
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.
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.
That is a bizarre fact.
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.
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.
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.
Granted this is my personal experience, I can't say this is the case for every single user out there.
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).
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.
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.
Maybe 40% of the developers I know use MacOS + Android.
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.
How should I interpret the following four paragraphs where you say what you want?
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?
... 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!)
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 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.
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.
https://docs.flutter.dev/ui/accessibility-and-internationali...
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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 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.
Seems like it is: https://play.google.com/store/apps/details?id=com.fluttersha...
You seem to say this like it's a bad thing?
But in this specific instance I was referring to OP’s claim that it’s impossible to identify many Flutter apps, which I dispute.
What's worse, there are new applications with custom look and feel that do the same navigational sins today
That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.
Frame buffer? Canvas is the javascript term.
There is a world outside the browser. For now.
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...
The other two are too new to be relevant.
The sometime subjective aesthetic reasoning doesn’t mean the application can’t succeed. office ribbon is an example
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.
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.
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.
Please keep your comments civil
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.
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
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.
No wonder it's not accurate.
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).
I've solved thousands of daily crossword puzzles in that app.
I can't tell if the same applies to Square or American Airlines but I would not be surprised.
I don't think that's the developers fault though, I don't have that issue with any other android app.
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.
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.
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.
whatsapp is the poster child of this technique btw.
So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
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.
Partially agree on the web sentiment, it just lacks a proper model, both positioning and styling, for what we call apps.
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.
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.
I think you are grasping at straws because you know you are wrong.
But limiting yourself only to standard widgets seems to be extreme.
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.
I like headers and sections more that tables for most things anyway.
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.
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.
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.
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 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.
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.
So success?
I mean, Google could also punt and let Flutter die. They've killed greater investments for less.
Do you mean https://wallet.google/, which says “only available on Android”?
Your parent comment asked for “on desktop or web”.
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.
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.
Just Google "bolt react native" they have jobs and articles about their usage but also any library inspector will tell you that.
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
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.
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.
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.
Which programming languages have a good developer experience with flutter beside dart ?
I know I use exactly one and it sucks. It’s all janky and weird compared to the rest of the system.
Maybe if you've never worked with TS/React and more generally HTML/JS/CSS, then it may be OK for some use-cases.
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?
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.
disclaimer: my team runs said infrastructure
That part is the killer. Important to the Google Flutter team != important to the wider Flutter community.
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.
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.
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.
They're slightly different things (as the post notes, the bigger number includes copy editors), but still…
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.
power(Python) > power(Erlang)?Suppose Flutter may be an order or two magnitude more complex than 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.
plus they said an "order or two" which would be 10-100x so ...
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).
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?
Python 3.13.0: 799.6559143066406 ms
Node 18.20.4: 59.34080000221729 ms
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?
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.
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.
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’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.
Billions per HOUR seems quite a stretch there..
Unless you're discussing background processes on google's side
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
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.
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.
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.
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 was a company acquired ala Firebase? Always thought it was a project (like Golang) incubated by/for/at Google.
https://dictionary.cambridge.org/dictionary/english/founder (n)
someone who establishes an organizationIt'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.
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.
The constant pressure to ship new features instead of only widely desired features overtaxes a team quickly.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Seeing as React Native has somewhere around 1 million active developers, Flutter almost certainly does as well.
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.)
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.
I’m pretty sure Node developers usually don’t install Node from npm.
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'm not sure what conclusions we can draw from either number.
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.
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.
[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.
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.
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_. :)
Hard to say it is "everywhere". It's probably more popular than any of the other cross platform alternatives though.
>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
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".
- 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
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.
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'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.
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.
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
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?
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
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'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 ?
They even have Ktor (Kotlin web framework) plugin available only in Ultimate. For any non-trivial Kotlin development you need to have Ultimate.
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)
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.
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?
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
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.
I was genuinely interested in your thoughts, "you wouldn't understand it, but trust me" is deeply unhelpful.
Glad you found it useful.
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.
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!
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.
Some relevant data:
- Over 165K GH stars
- Over 140K subredditers
- Over 500K YouTube subscribers
The 1M estimate is at least ballpark accurate.
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).
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.
How does it compare to React Native from user and developer experience perspectives? Are there other competitors?
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.
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
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.
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.
NativeScript
The developer experience was great and the Flutter team was very responsive with questions I asked.
The other xplat framework same as Flutter:
- React Native
- Kotlin Multiplatform
- NET MAUI
- NativeScript
- Slint
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.
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.
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.
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.
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.
Can you make any comment on this? Is it accurate?
Is it time for HN to finally support Slack-style emojis?
I'm almost positive you, personally, could implement support for those emoji short codes via Violentmonkey
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.
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.
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
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”.
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.
Anyway, my bad.
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 only see a single name?
Is this just some dude with a blog?
Isn't flutter from google?
"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.
I find it odd that you would think this fork would even have an impact on Flutter or its roadmap.
Which will be responded to swiftly with no lawsuits or damages exchanged.
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.
$ curl -I https://storage.googleapis.com/flutter_infra_release/releases/stable/macos/flutter_macos_3.24.4-stable.zip
< content-length: 1575089988
(nod)https://opensource.googleblog.com/2022/09/flutter-slsa-progr...
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
Compared to js, react & react native, python, ruby etc I've just never hit the same bitrot so they're doing something right.
Was created for flock?
This seems less of a fork and more of an attempted annex
The SQLite developers must find this rationale hilarious.
Are there no escape hatches?
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.
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.
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.
EDIT: minor wording
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.)
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.
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.
It’s the Dart Team that is focused on Flutter.
The community is oriented towards having one framework or library for doing one thing.
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.
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.
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.
Some related iOS jank issues from that time: https://github.com/flutter/flutter/issues/32170 https://github.com/flutter/flutter/issues/61450
Seems like most issues could be solved with new Skia graphite backend
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.
>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.
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 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?
https://twitter.com/migueldeicaza/status/1778759403451081159
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.
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?
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.
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'd rather put my money behind KMP by JetBrains. It has a more streamlines, practical, and consistent future than flutter, react native et al.
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.
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.
https://discourse.ubuntu.com/t/refreshing-the-ubuntu-desktop...
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.
It's on the front page: "A Global Open Source Community. Supported by Google, open to everyone."
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.
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.
>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.
It's claiming that people who produce penicillin, are responsible for billions of people who take penicillin.
That's a fair claim.
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
they could pay contributor or issue bug bounty..
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).
Given that you could probably make a similar assertion about any popular framework, this doesn't strike me as particularly relevant.
It's not linked to anywhere and not listed under the flutter github org...
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.
This point seems like a callout to a certain discussion and I kind of want to see it
If everything the article says is true, should I switch to Kotlin?
In all honesty, good luck. It might be useful if it never breaks compatibility with Flutter.
Or do you mean the UI Apple uses on top of swift?
Cripes I wish people would explain who "we" is. "Flutter Foundation"? Which is "Flock" but not "Flutter"?
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
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.
> 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.
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 scope of Python's standard library is just enormous.
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.
Other parts are written in Dart like you said.
Launched, abandoned. Scammed again.
When are you all gonna learn?
This could explain a lot.
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
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.
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.
Python started in 1989, it's older than Linux and it has a more narrow scope.
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...
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.
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.
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.
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.
But that leaves Python slow and single threaded.
Maybe they have more time to work on the software because of less overhead...
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.
- 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?
* 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.
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.