Hello, I'm from the Flutter desktop team. Thank you for the excellent feedback, this is truly invaluable.
Here are some updates from our side:
1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!
2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw
Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!
Google's Flutter team was affected by layoffs and we lost some wonderful folks. However, the number of Googlers working directly on Flutter has grown substantially in the last year.
Please keep in mind that Flutter is a community project. Google is one of Flutter's many sponsors, many of our contributors are from other companies.
A community project? Flutter.dev literally says "Flutter is an open source framework by Google [...]" There is no list of sponsors on their webpage either, only a list of companies using Flutter. Google owns the logo and the trademark, controls the github repository, etc. Having contributors from other companies does not make the project into a community project.
Is there a CLA? Do I have to waive ownership of my contributions for my code to be merged? If yes then it's not a community project. Domain ownership has little to do with it. Look at who owns github.com :)
There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.
It's open source software, developed in the open under a permissive license. You don't have to work for Google to have contributor access or the right to approve others contributions. Google kindly sponsors a fair amount of infrastructure (testing labs, etc.) and pays for a lot of people to work on Flutter. If that doesn't meet your definition of "community", then fair enough -- but the spirit that we work under is that the "Flutter team" is everyone who contributes code.
Hey, first let me be clear that I think it's great that Google is developing Flutter in the open, publishes it under a permissive license while also trying to get along with other contributors.
However, it's not a community project, by any definition of community, because there is a power imbalance between Google and other contributors. Accepting patches or even allowing non-Google people to accept patches from anyone is not enough.
> There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.
No, there is a CLA so that Google keeps the ability to relicense future Flutter releases however it seems fit.
Of course everybody owns their own contributions, git log clearly shows who owns what. BSD license already assures that they are free to be used by others, and if patents were a concern, AFAIK the Apache license would've been a better option (IANAL). You don't need a CLA for any of that.
Users and contributors are bound by the BSD license. Google however gets special treatment:
"""
Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
"""
I hope the power imbalance is clear this time?
Again, it's great that Google develops open source software under a permissive license. Mad respect. I'd happily sign the CLA were I to send code to Flutter. I'm also not saying that Google shouldn't have a CLA, I fully understand, and maybe I'd do the same (maybe not). But let's call it what it is.
> but the spirit that we work under is that the "Flutter team" is everyone who contributes code.
Sorry but you sound like that boomer SMB owner who keeps saying "we are a family".
CLAs are always a good idea if one is maintaining an open source project. I'm not going to track down every single contributor who made some small PR perhaps, just to make a license change.
The license could change for any number of reasons, making a paid version, making it GPL, etc. With a CLA, I don't have to assume, I'm able to change it regardless, that's why for maintainers they are useful.
Keeping the software free, i.e. not proprietary, even from maintainers trying to make it so, is the very point of GPL.
When you ask contributors to sign a CLA, you are saying that you might want make it proprietary in the future and reserve the ability to do so. You should never sign one if you don't want to contribute to proprietary software.
I very, very strongly disagree with this. On web, Flutter is flatly awful (and there’s no reason to expect it to get much better—it’s chosen a paradigm that makes it impossible to do a good job on the web). On desktop, well, this article describes various limitations and problems.
Flutter is unquestionably designed mobile-first, with everything else a distant second. Flutter may be the best option for developing cross-platform mobile apps right now (I don’t know), but if you care about web or desktop, it’s not a particularly good choice. Things based on web tech are very likely to be better.
Thank you for the great work! Flutter and Dart are awesome and keep getting better. I'm coming from the land of Scala, Erlang, Clojure, TypeScript, and I'm loving the general approach to the engineering and design that Flutter and Dart teams have. Kudos!
Do you have any pointers for someone who would love to contribute to Flutter and Dart as an open source contributor? Is there some guideline for what kind of contributions will be considered, areas where contributions are desired, etc?
For a lot of first-time contributors, improved documentation and added tests are a great way to dip toes into the water. We also have a 'good first contribution' tag on our issues log that might be a source of inspiration:
https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...
I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?
i will start by saying i love dart. i learned it solely so i could make flutter apps. but now, three or four years later, i can say for certain that i love dart a lot more than i love flutter, which i have mixed feelings about.
i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i wrote, in python, to automate away the boring parts of my job, which i am now converting to dart. at this point, for me, trying to get anything done in python is like wading through molasses. (like, why does almost any change to a python implementation file cause you to also have to revisit the imports section? ugh, i hate that so much.)
my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. programming is thinking, and i really don't like you dictating the way i ought to think. (yeah, i know you won't do it, but that's my big one.)
my second big change would be to allow me to implement a big dart class in two or more implementation files. the business logic in the flagship flutter app i maintain is getting unbelievably complicated, and large chunks of it cannot be moved out of the one object it is in, due to inheritance reasons.
> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance.
Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.
> my second big change would be to allow me to implement a big dart class in two or more implementation files.
You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:
the syntax is similar to C/java/C++ so the out-of-box experience was great, please keep it. I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.
I use dart for scripting as well, which works really well.
For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable instead of depending on system C shared libraries.
I gave up on Go and embraced Dart, so the `dart build` and `static binary` are kind of what I missed from Golang when started with Dart.
> I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.
It's "dart compile":
$ dart compile --help
Compile Dart to various formats.
Usage: dart compile <subcommand> [arguments]
-h, --help Print this usage information.
Available subcommands:
aot-snapshot Compile Dart to an AOT snapshot.
exe Compile Dart to a self-contained executable.
jit-snapshot Compile Dart to a JIT snapshot.
js Compile Dart to JavaScript.
kernel Compile Dart to a kernel snapshot.
not really, dart-compile does not do pub-get automatically, while dart-run does. dart-build is basically a (pub-get + dart-compile) to be "consistent" with other modern languages such as 'cargo build' or 'go build'
Yup, but we're focused on mobile first as these are the most resource constrained platforms. We're also experimenting with 3D support in Flutter using Impeller. Check out these demos from Flutter Forward: https://youtu.be/zKQYGKAe5W8?t=6955
Something being highlighted about Flutter is that it ultimately compiles to native code so unlike RN which transpiles to native widgets, its UI animations should technically be buttery smooth.
But in watching the flutter announcement video https://youtu.be/Nu5m1FiS5X4?t=60 (timestamped link) on the screen as menus are opening and the mouse cursor is shown selecting different items, there is... a very perceptible stutter and lag. What is that due to?
* Of a video made by a separate video production team...
* Based a slideshow (probably Google Sheets)...
* Containing a pre-rendered video...
* Of a screen recording...
* Of a Flutter desktop app.
Any and all of those can introduce latency or lag in the video. It's a great form for showing users features, but probably not a great way to evaluate UI performance, unfortunately.
this just makes me think of the fact that this sort of thing would absolutely never fly at Apple. And I really, really want to say that is shouldn't fly at Google either. They're spending what, 400k on the median developer annually? Have standards, make them have some sense of responsibility and respect for their craft so they don't do this. I mean, like come on, one of the main value propositions for someone considering Flutter as opposed to RN is the fact that it isn't transpiled, there is thus an expectation for widget performance to be basically be similar to that of native code -- well, this is exactly where you proudly and loudly showcase this -- in an announcement video. Widget performance should be absolutely flawless in the presentations.
But all that said, no I don't think that's what's going on here. The things shown right thereafter are stutter free. I think this is a quirk with Flutter. While for mobile/desktop it compiles to native code, for web it does transpile to JS and I think that's perhaps what is being shown there. Though I would think if they wrap it in some sort of wasm the lag wouldn't be perceptible.
It just really grates me that in this day and age this is the reality of UI. If you'd told me 10 years ago that a simple menu shown in a major UI toolkit announcement by the main web player would have these kinds of problems I'd have assumed you were just bad at telling jokes. It also makes me sad because I want Flutter to succeed but seeing these kinds of missteps gives me a pause.
edit: I see now that you're a googler, I'd have phrased it differently if I'd known. Cheers.
Hi! I was wondering about the coexistence of Flutter and Kotlin in Android development. Is there any good write-up to help devs to choose between them depending on the use case?
Not who you want an answer from but for me if I was writing an android only app I'd go for kotlin, if I wanted android, iOS, desktop, and web I'd go dart/flutter.
If there's anything I've learned from using Google projects it's this: It's not going to get fixed.
It almost doesn't matter what it is.
If you've used any Google OSS project seriously you're going to come across an obvious defect and run to GitHub to open an issue. But, there's already an open issue for the problem.. And it's been open for almost as long as the project has existed.
It will have an inscrutable priority and day after day new comments will pop up saying "Hey, I'm having this issue too. Can I contribute a fix?" But, a pull request with a fix has sat, unreviewed, for almost as long as the issue has been open.
And then it comes: "This issue has been automatically closed due to inactivity."
Every time I see "closed due to inactivity" implemented, the outcome is that new feature get added rather than fixing existing problems, because the memory of those problems only persists in the users day to day life. The developers have no useful record.
But, I doubt that can scale. I imagine there's some happy place sitting near semi-automated "duplicate" recognition, and a voting system, to give the users a voice. Closing due to inactivity is never a happy place (unless it's sitting waiting for required user feedback maybe).
You haven't really used a Google open source project unless you've filed a bug, had it assigned, had it automatically closed after months of inactivity by some PM cleaning possibly obsolete bugs, reopened the bug, rinsed, and repeated for a decade.
For me, Flutter mobile isn't there yet either. I can see where it might be great for games with completely custom UIs, but I find the uncanny valley of pretend native controls a very uncomfortable place to be.
Flutter could be a fantastic solution if it supported native controls and used JavaScript. I don't understand why Flutter's creators are so seemingly religious about Dart and reimplementing OS UI capabilities.
Every technology is a set of tradeoffs, including Flutter.
For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care if the application looks pixel perfect (but, still, Flutter is definitively an improvement from Oracle Forms :)
What users and the management does care, on the other hand, is that the features can be delivered quickly and on multiple platforms.
> For me -- I am using Flutter to build internal productivity tools available on multiple platforms (web, desktop, mobile). Users do not necessarily care
Have you measured it, or did you stop after the Form A Hypothesis step?
Isn't what you're describing basically React Native? I think the Flutter devs wanted to try a different approach to address what they felt were the shortcomings of React Native which brings along its own set of tradeoffs.
Sure, but most common mobile apps ARE completely custom UIs which insist on their own branding and look. The UI designers usually really hate if they have to use standard components and are unable to express themselves.
Agreed, most apps I use already don't use native controls, like Slack, Discord, Spotify etc, and I don't want my apps to do so either since I have a custom design. I think people on HN think users care about platform UI when we see that most users really don't notice or care.
That depends on what kind of controls though. Many apps will their own buttons, but most are using the native text input control (and often the native scroll for screens / screen transitions.
On iOS it's not too difficult to build a fully custom UI with just UIKit. You want a totally custom button? No problem, don't fight the styling inherent with UIButton, just subclass its parent class UIControl instead which is a blank canvas, but still gets you 90% of the perks of a standard UIButton with minimal effort. It's pretty easy to write entirely custom widgets with unique behaviors too.
It's a bit more messy to do that with Android Framework, and because of that I see more of an argument for using Flutter there than on iOS. Jetpack Compose seems to be a lot better in that regard though.
You're definitely not alone in this. One of the core reasons my team chose Flutter was the fact we would not have to spend much time setting up development environments and making sure we were always using the latest and greatest framework.
You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.
Again, it's definitely not free (or "basically" free, either). Step 1 negates that statement. You have to set up a development environment. It takes some non-zero amount of effort.
In contrast, the browser is already there. It already runs JS. You don't have to do anything to make that happen[1]. And in saying it takes nothing, that's not merely "basically" nothing; it's literally nothing.
> Instead of installing/configuring/setting-up npm [and a bunch of other crap]
What if I told you that while you're free to opt for doing any/all of those things, none of it is actually necessary, let alone a good idea? (Or point out that TypeScript is not even JS, for that matter?) That you're totally allowed to ignore the GitHub busyworkers and write actual (i.e. straightforward, standards-compliant) JS—in contrast to much of what's available for NPM/NodeJS, where you are most often encouraged to write "JS" that's incompatible with what's in the standard (and what the browser makers actually implement)?
You seem to be suggesting that instead of installing a piece of software and running two commands is somehow inferior to writing untyped, unscalable javascript, hard refreshing the page each time to see your changes, loaded in yourself with script tags. This is the oddest argument of all (I can use that word too)
There is a reason people made these countless frameworks and solutions, but the benefit Flutter provides is it's an out-of-the-box fix, and yeah, installing some software and running two commands is an out-of-the-box fix.
In addition, the entirety of your argument just flat-out ignores the cross-platform aspect of it, targeting only the browser instead of mobile and desktop platforms as well.
> You have now transitioned from saying that you don't have to spend as much time to set up a development environment to saying that it is pretty much free, which is even odder still.
I truly don't understand this odd exercise in linguistic gymnastics, as these are both simultaneously and entirely true. You can resolve this yourself.
> You seem to be suggesting that instead of installing a piece of software and running two commands is somehow inferior to writing untyped, unscalable javascript, hard refreshing the page each time to see your changes, loaded in yourself with script tags.
Nope.
> This is the oddest argument of all (I can use that word too)
Oh, boy. That sounds bad. I guess it's a good thing that's an argument I'm not making it, then! (Also: I didn't use that word, FYI.)
Are you sure? The "whole JS ecosystem" you're aware of is likely to be the trendy (e.g. NodeJS+NPM) one*, which bears indicators at just about every turn that many/most of the folks working in it don't actually like the language themselves which results in lots of their energy being spent trying to fight with it which in turn produces the sorts of things that I'm guessing you like least. (For example: `package.json` is a tastemakers' invention and didn't appear anywhere in the spec.) This gives a skewed impression of what JS really even is; the dominant culture you see on GitHub is not the inevitable outcome of settling on a decision to standardize on JS.
(This isn't to say that the suggestion from the original comment you're replying to was a realistic/reasonable one in context.)
* in other words, not the "whole" JS ecosystem—you probably aren't looking at use of JS in, say, Gnome for example
> I don't understand why Flutter's creators are so seemingly religious about Dart
I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.
Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.
In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.
I don't think it's necessarily an error to reimplement widgets, with a caveat — the reimplementations need to be good. Really good, at least as good as native widgets and preferably better. An example of this is Sublime Text/Merge, which feel excellent despite being built with a bespoke UI framework.
This rarely happens though, and I wonder if it may have to do with the limitations of the technologies often chosen to do the implementing with, or if it's more of a philosophical thing with the projects in question not holding themselves to high enough of a bar.
> I find the uncanny valley of pretend native controls a very uncomfortable place to be
Me too, and I’m surprised how okay with it people seem to be. What are the odds that Google to continue to support the latest platform UI changes? What about five years from now? How much effort is it to get good accessibility support vs native controls, and how likely are developers to do that?
The whole approach seems wholly dependent on Google continuing to give a shit, and as we’re all aware they don’t have the best track record there.
The more "solutions" that are developed for desktop + mobile cross-platform applications, the more I see highlighted how different the paradigms are, and how the streams really shouldn't be crossed.
They're both UIs viewed on a screen that you interact with by pointing and clicking, but the similarities end there. The entire output of this cross-platform effort has been awkward applications that run everywhere but feel right nowhere. It's sad that even Apple has fallen victim to this idea that with their horrible Catalyst apps. Though I understand why the sales pitch of "one codebase" makes management of so many companies salivate.
Not sure how to interpret. Pro Qt or pro wx? I'm assuming the latter.
But I don't even agree. Qt is/can lay claim to native as much as anything else on desktop Linux/BSD. The quality of the Windows emulation has always been excellent as far as I'm concerned, at it's been pretty goodish on Mac.
But I've never seen a perfect cross platform library that targets Mac.
wxWindows may use system drawing at the low level, but those that have been in this for years know what's up: it's just an unholy messy quasi-MFC (Microsoft Foundation Class) looking thing - the model is inherently MS Windows from 1994. This is not magically going to work well as a Cocoa app just because it uses NSViews under the hood. And although the simple controls may use the OS, all the complex ones have tons of internal design. Like this is optimizing the wrong thing - as a normal person I probably care more about the look and feel of the tree view, whereas only the weirdos on here are going to get bent out of shape that some button text is a few pixels off - getting both right is nice, but only hitting the last one is pointless.
I've never seen a nontrivial wxWindows app that would fool anyone on MacOS. Qt can get much closer if you work at it a bit.
So in practice I would say you can do better with Qt for the major desktop targets.
These are all compromises. And native hardly means anything these days. Yes Windows has what has been retconned as WinForms, but otherwise, the UI LnF of Mac OS is a constantly moving target and Windows has never been as consistent as people seem to believe. Linux/Desktop Unix - lol.
Fully native isn't especially realistic. At the risk of sounding like a broken record, general purpose tooling written by a small team can't support multiple native UIs.
What often works for me is something like Wails, but it has its limitations. For instance there's no multi-window functionality there either, and while the new Wails supports more OS integrations there's still some aspects that need improvement to compete with native UI.
I'd love to try Flutter, but frankly I don't want to write "backend-ish" code in Dart. There's some projects to be able to build UIs in Flutter and have processing done by a separate language that all gets bundled as one, but they're mostly hobby projects.
Having worked on projects for both mobile platforms with small teams, I find that cross platform UI frameworks only really make sense for somewhat simplistic apps. The more involved the app in question is, the more these frameworks incur overhead with the extra surface area for bugs to occur on which is multiplied by the number of supported platforms.
The story on desktop is a little better but the same principle applies to some degree.
I'm using flutter_rust_bridge, it works pretty well. However, I do like Dart due to a few features it has, like code generation so that I can build my own language features if I want to, I use that pretty extensively.
If you have the money, make everything native, but until then I can build a Flutter app that works on 6+ platforms for the price of one, which is a real competitive advantage for a solo developer running a startup.
One thing I learned though... if you say are going to deploy on say, Android, you are not getting away from its dev toolchain and API if you want to do anything non-pedestrian. Same for iOS and possibly Windows.
So you often end up really having to learn N+1 platforms.
I think Flutter is the best option right now to release your idea on mobile, web and desktop platforms yourself without hiring additional people. The only other realistic option I know of is to use web tech. Are there other good options for single devs?
The point of seriously (key word) using x platform tools is to ship fast and solve customer problems.
If the particular experience you want isn’t supported, creativity is required to either:
A) use an alternate experience. Users literally don’t care as long as their problem is solved. They don’t care if it’s using X api or multi window or whatever. Just use tabs for all they care.
B) build the experience as a lib and maybe open source it
Well, web designing does blur the lines. You can easily create a website that is both desktop and mobile friendly by implementing responsive design. Translating that to a native experience seems to be the problem
I largely agree with this when the application will be used heavily on each platform. I think desktop + mobile cross-platform does work when one platform is primary and the second secondary (ex. IOT devices). You can then have an interface primarily focused for an embedded application, and then when data transfer or settings for the embedded device needs to be configured, configuring it from the desktop is easier, and having a similar interface all around is beneficial.
I wonder how many people Maxis employed when they made Sim City 2000? Because it had a native UI for every platform it was ported to that had a windowing and widget toolkit.
I just can't help but think that either programmers today have abstracted themselves into a lot more work than need to do, or they're just significantly less capable over all than the programmers of old.
As someone shipping an app across all desktop and mobile platforms with flutter, binding it into a native rust library, I absolutely adore it. It does what I need and is fairly reliable about it everywhere, while keeping build systems and everything else mostly managed for me. As the post mentions, it’s not a panacea, but for someone who needs a good-enough solution, it’s been great.
I most recently tried out Flutter about a month ago and "not there yet" feels like my overall experience. Sadly for a project of Flutter's age one has to wonder whether the "yet"-phase will ever end (just like some libraries are bound to always be buggy due to their architecture, while others feel smooth).
In onboarding to the tooling, there are so many paper cuts that it's not really a "I'll try this out for fun" thing like e.g. Next.js is, that you would recommend to your co-workers.
I tried it out for desktop, where I found it okay-ish (but lacking in desktop-related libraries, as the article points out), and for web, where the debugging experience compared to web-native solutions really takes a hit due to the lack of DOM.
We actively use Flutter and tend to agree with this sentiment, with the caveat that we believe it absolutely can get there (and I believe a lot more in Google's ability to stay relevant than Facebook's, even with ChatGPT in the mix).
That being said, they have a lot of work to do.
- I'm not a big fan of Dart's overall composition
- "late" seems lazy and error-prone
- Dependency on code generation for simple things like JSON serializers/deserializers
- All the other issues people have mentioned in this thread.
Luckily my team is investing a lot in our developer tooling, so we can lint/codegen a lot of the stuff away, but it's certainly a sign of it not being there yet.
Indeed, multi-window support is absolutely missing right now, but it's the Flutter's team top priority. Context menus are now available with 3.7.
Generally, I found Flutter/Dart easy to pick up and build a quality desktop app with ease. Currently, I am not convinced that it can be used for performance-critical apps yet without a lot of developer effort and experience (there is, for example, Rows, an Excel clone built with Flutter). However, it works for building general-purpose apps on desktop, without messing with the native toolkits that are in a strange place, especially on Windows.
Not having any experience at all using Flutter, nor do I have any interest in doing so - just wanted to say that your blog article was a fun read. Thank you for sharing! :)
Flutter is going to be 5 years old soon. It's not even the leading solution for cross-platform development for mobile let alone desktop. It's great to be positive and supportive but realistically, if someone had to bet months of dev work on building something non-trivial - would they really choose flutter?
I'm betting the farm on Flutter. I'm building a relatively complicated app that's integrated with native C code on iOS and Android. Before I decided to go with Flutter/Dart, paradigms that I knew nothing about, I experimented with all of the major frameworks. React Native, Expo, Ionic, Capacitor, etc. I chose Flutter because it had the best performance for what I was doing around high-performance audio. Flutter is allowing me to continuously move forward and make real progress as a solo dev. I'm finding the DX better than React Native. I'm going to need to make a related tvOS app as well, but not sure how well Flutter can support it.
It’s hardly some toy SDK that is only suitable for MVPs. Google’s single biggest money maker Ads is built with it. It’s hardly a Google specific thing either there are a number of mega sized players also strongly betting on it for some fairly mission critical stuff if I understood correctly.
> Google’s single biggest money maker Ads is built with it
You mean Google Adwords right, the admin panel? I can't see any evidence of that, nor is it listed at https://flutter.dev/showcase, where you get this from?
Right, when people say "Google’s single biggest money maker" they're talking about Adwords, which is usually accessed via the web, not a Android app called "Google Ads".
To be fair, it's all the same thing underneath, the Ads app is the same as AdWords on web. "Google's biggest money maker" isn't referring to either AdWords the website or the Ads mobile app, it's talking about the underlying ads product itself, ie what gets shown on websites, these are simply UIs over that.
Clearly not, the AdWords on the web is rendered using the DOM, while a Flutter application will be rendered via a canvas DOM element.
You can try this yourself by opening up the inspector.
Where the ads are mostly shown, is also built using normal (in the web sense) DOM elements, either images or text, rather than Flutter canvas elements.
By "same," I did not mean technologically; as I pointed out in my other comment, I know AdWords is made with AngularDart while the Ads app is made with Flutter.
By "same," I meant they are equivalent in functionality (or nearly so, based on the differences between larger and smaller UI sizes). Both AdWords the Website and Ads the Mobile App are all part of the same Google AdWords the Product.
Our team choose flutter 3 years ago, we currently serve 2 million users. I attribute a big part of our success to Flutter and the flexibility it gave us as a growing startup.
Another one, desktop webviews don't exist either. Everyone does something custom right now and there's an epic vent fest in one of their GitHub issues. This causes about 1 new package to get released every few months too that tries to address it.
Hey there - Flutter team member here. Support for integrating arbitrary non-flutter views/widgets (referred to as PlatformViews in Flutter terminology) is something we're actively working on at the moment, once we've got them landed, web views and video player support are top of our list in terms of views to add support for. We know people can't wait for this to land, and believe me, I can't wait for it to land either :)
PlatformView support is one of our top desktop priorities this year (along with multi-window support).
Hello, I'm from the Flutter desktop team. We're actively working on adding platform views to desktop, which will allow you to embed web views into your Flutter application. Stay tuned :)
A good example of Flutter desktop is https://rive.app/downloads - curious on others' thoughts of how that compares to Electron or other choices that are out there.
Docking would be nice to have too! like what MSVC or Qt has (built-in in Qt is not that great, but Visual Studio is one to follow). It's a must for content creators with multiple monitors, especially if they want the layout to be preseved from session to session or create different layouts (e.g. how and where the windows are, what is docked in which other, etc) for other people as templates.
That’s because the Android emulator sucks for development.
There has never been an iOS “emulator” for development. When you built your code to test on the desktop, it was compiled to x86 and used x86 version of the iOS framework.
Of course now that Macs use ARM chips, it’s a moot point.
The basic functionality of the typical UI hasnt changed for ages. Yet technologies keep churning. There is probably a better way but apparently people are not incentivised to find it.
This is a strange take for me- people are CONSTANTLY trying to find new, better ways to do UI. Elm, React, DearIMGUI, Flutter, and Xilem are some of the more well-known fairly recent libraries.
His point stands for me as well. I saw a lot of huge potential for cross-platform mobile development but desktop feels like a bad port of a mobile app rendered on desktop.
I LOVE Flutter for a web / iOS / android side project.
It's a Spotify music player that turns your device into a jukebox at https://getjukelab.com/.
As a hobbyist I couldn't imagine getting this far on 3 different platforms if I had to go native. My favorite surprise is how much faster doing dev, deploy and QA on the web target is, vs doing mobile dev and release. I can deploy to the web 5 times a weekend, and batch those up to do monthly mobile releases.
I tried Flutter Desktop but hit an immediate show stopper that the flutter Spotify SDK doesn't support it. There's no "Mac Spotify SDK", so it would have to wrap the web one somehow. All the UI bits worked as expected.
But watching the trajectory of Flutter and the community over the past couple of years I'm cautiously optimistic it'll get good.
I've been very disappointed with the direction of Flutter recently, but I still do stand by it and will always choose it over the GatsreminextstroJS framework for VuengulembereactelteJS.
Why are 3D, game engines, and WASM more important than good JSON serialization, improved runtime safety (removing "late"), multi-window support, extension structs, webview support, exhaustive maps, and other core issues?
Here's my quick criteria for whether I should use a new framework for my app:
- look at other apps that are using that framework, esp. the signature/first class app touted as a consumer by that framework
- how similar is my app to that signature/first class app?
- if my app has similar UX/UI usage then the dev experience will be much smoother/easier/doable
i.e. for React Native: does my app behave like Facebook? If not (say, an action game as an obvious typical non-usage scenario), there be dragons...
for mature, stable frameworks like native mac OS<=9, macOS, Win32, most GUI apps are straight forward, it's when you push the limits of the UI where things will hit hurdles.
So what's the signature/first class app for Flutter Desktop?
This is exactly why even after I made the decision, I’m still somewhat hesitant on learning Django. With RoR it’s a different story, but Django is a bit weird in this regard (users, references, popular applications).
A couple of thoughts (doesn't address all the concerns):
1. I write in Rust, so my plan was to write the UI in flutter and use the rust/flutter bridge so I can write most of the client code in Rust. Gets around _some_ of the lack of flutter libs by using Rust ecosystem instead (but not for the UI itself)
2. There is a new lib out called platform ui that wraps mac/windows/linux UI transparently (it is just a wrapper that wraps fluent ui and macos UI libs, etc). Not sure how well it works, but might worth a shot and gets closer to native l&f for desktop
I have 2 LOB on the desktop. Is Jank an issue? Only to those who have 100+ refresh rates.
Corporate wise , nah, its fine, Jank effects heavy animations. Even then the 3-4 encounters was fixed by some smart resource usage. We are trying the 3.7 solution. If not, then stick with the idea don't try to animate the animation.
Desktop ready? Corporations yes. Make the next unreal 5.x game with it? nope.
One single platform for cross platform development is enough motivation and react native has improved a lot in the past year.
The entire concept of developing the same app multiple times for different platforms is just so mind numbingly dumb. 3x the engineering team, 3 different platforms with all their different idiosyncrasies. The impossibility of maintaining feature parity across all three platforms. 3x the testing and debugging.
I can see some apps needing to be native (ex: using AR/ML libraries where you need to squeeze everything out of the phone). However, for most apps I use, they could easily be mobile optimized websites wrapped in an app.
I’m surprised anyone would trust their UI core technology to be something from Google. They kill projects left and right, and that was before the layoffs.
I've written a few Flutter apps. The problem is dart is just not a good language and not something you'd want to use in 2023.
The Flutter team should consider unpegging from dart and utilize JavaScript/Typescript, Kotlin, or Swift.
We've been telling Dart team our complaints but they have been unaddressed for over 8 years now. At this point, some other thoughts include applying a garbage collection cycle and have them replaced by Carbon team or Golang team.
Perhaps get a new product manager, someone that will listen to the grieving (& dying) dart community.
It’s been 5 years since I left my Dart team at Google. Still shocks me how slowly that world moves. There’s just no sense of urgency when AdWords revenue showers you with unlimited sums of money.
And probably never will. There are a bunch of projects but they are not very good or complete.
The problem is that "good" requires massive amounts of work that is beyond the capacity of single person / small team of volunteers i.e. typical open source project.
Which is why Flutter (and Electron) are the only reasonable technologies for desktop apps that I see today (and in the future).
They get majority of investment from other place: 99.99999% investment in Electron is investment in Chrome.
99% investment in Flutter Desktop is investment in Flutter Mobile.
Flutter Desktop and Electron will continue to benefit from massive investments in Chrome and Flutter Mobile. No other project building desktop UI can come anywhere close this level of investment.
Coworker of mine is using Fyne (for Go). So far the one issue that was found was the use of OpenGL, which on certain video cards, on Windows, in a remote-desktop session may not work (it works if you have NVIDIA drivers for example), or if you force `mesa` software rendering on top.
These little details are usually not a concern, until they become a sudden requirement. Another one is Accessibility, which actually helps in other ways - you can automate UI test, or just automate things through it without relying (to a degree) on the kit's framework. In a way it serves to prove that the UI toolkit does diligent job of presenting it's widgets to a Reader.
I recently tried to use Flutter to develop a Windows desktop app, and I hit a wall. Unfortunately I'm using an arm64 machine, and I ran into enough mysterious errors that I just gave up.
This article really needed to be longer and have some illustrations. What's the point of publishing an essay about interface design without including any graphics?
I'm sympathetic to the points made, but as someone who has not used Flutter, I really do not have a sense of what the tooling and output is like based on this short piece.
Ok, it's isn't "there" just yet, so what? They are working on it and doing a great job so far. It's not perfect, but nothing is.
I has saved me and my team countless months so far in time to ship a truly cross platform product and I'm sure there are many others like us who feel the same.
It is great to point out things that need improvement, but going so far as saying 'it isn't there yet', seems extreme.
If your use case requires these specific issues to be sorted, then it is great to know about them in advance. Nothing is perfect and every single app across every single framework is going to need to make trade offs.
If I needed text selection to be faster than what the built in component offers, I'd just develop my own component or spend some time debugging why the existing component is slow. Flutter itself doesn't prevent you from doing this.
If I needed multiple monitor support in my app, I'd probably not write it in Flutter because I looked at my app requirements in advance and realized that it doesn't support that.
The rest of the post seem to revolve around not having enough built-in ways of doing things. Again... you can't expect someone else to write your code for you and then call the whole framework lacking.
I’m sorry, but not supporting multiple windows (not monitors!) in a single process, and not supporting bog-standard desktop features like context menus, rightfully qualifies as “not there yet”.
It really depends on what the app you're developing requires. My app is just a few buttons for inputting data. I don't need context menus, multiple monitors or text selection. Thanks for the downvote though.
Although true, HTML doesn't let you customize context menus or (easily) open multiple windows either, and UI interactions frequently lag, but it's used for general desktop development all the time. These issues seem to be more that describing something as for desktop development raises the bar fairly significantly in terms of expected feature set. That's reasonable, but we should be careful in describing something as unsuitable because it lacks things HTML also lacks.
FWIW, I don’t consider web applications to be a suitable replacement for native desktop applications, not the least because they lack support for desktop UI conventions, which do exist for a reason; although it is true that many people nevertheless make do with web apps.
For the note: Sciter is an embeddable HTML/CSS/JS UI engine. For desktop and mobiles. By feature set it overlaps 96% with Flutter. It differs in ideology and implementation significantly though.
0. Dart
Not clear why Dart is used in Flutter. By architecture and feature set Dart is almost Java.
Why the Dart then? My guess is this is an attempt to simply replace Java on Android without changing existing UI paradigms. Yes/No ?
1. Desktop-first vs. Mobile-first development
Desktop UI is windowed one - UI may consist of multiple desktop windows: frame, dialog and popup windows. There is also a concept of "kiosk mode" in Desktop UI - single window spanning whole screen.
Mobile UI is a windowless thing - UI canvas spans whole device surface.
As you see Mobile UI is Desktop UI in Kiosk Mode - Mobile UI is a subset of Desktop UI.
Transition of large subset system to superset system is quite hard. On top of my mind I cannot tell any success stories of that. Anyone?
2. Separation of concerns
95% of UI development these days is a Web UI that uses three pillars: HTML as a semantic UI declaration, CSS as a style declaration of UI states and JS as declaration of event flows and UI state transformations. Essentially script is a definition (declaration, again) of flows/routes - how output of one native function is connected with input of other native function.
These three pillars, their purposes, are so different that their syntaxes should be different.
Attempt to combine all these definition in single language is doomed to fail. If in doubts then look at WPF.
3. Notes on language-behind-UI...
If to consider #2 then such simple thing as JavaScript language and VM are quite adequate to the task. Language-behind-UI do not need to be that performant, but it must be flexible. I may express un-popular opinion but language-behind-UI should be typeless.
Simply put: don't do ray tracing in language-behind-UI. But! Such a language shall have simple mechanism of adding high performant functions. There are good languages that are specifically designed for performance: C, C++, D, Rust, Zig, WebAssembly, etc. You just need convenient mechanism to expose those functions to runtime of language-behind-UI. Like here: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...
You need JITs, compilation, fat VMs and runtimes, strong types only if your language is the only mean to define algorithms in whole application. But expect that your code will always be sub-optimal - neither enough performant nor super flexible.
4. Conclusion
Flutter should be something Sciter-alike :) - use [X]HTML/JSX, CSS and some already well known language-behind-UI. JavaScript is the natural choice. If needed you should be able to use native UI components - like in Sciter you can use existing HWND based and windowless native components inside your UI. It may not follow Web UI model on 100% (that's impossible) but to be conceptually close so developers can reuse their skills. Web UI model is conceptually close to Mobile one - whole applications UI is constrained inside single window.
To me as someone who recently got into Flutter to make a side-project (mobile game) the most glaring problem isn't the lack of ecosystem or little UI issues the author mentions but the language itself. You had a green field to make the best programming language for creating UIs and you made Dart? Like what.
I don't have particular issue with the heavy OOP paradigm but the fact you have to write so much boilerplate feeling code (Center here, Container there) you'd imagine you could have simplified it a lot more. The documentation itself also seems like it could be improved. And some little things here and there, like the constructor syntax. I dislike semicolons as well, to me they're just busy work.
Idk, you'd think an org like Google had the resources and the talent to make something truly amazing. Guess it just shows money can't buy everything. The tooling however is quite amazing. Being able to make cross-platform apps so simply is pretty awesome (React native was a pain in the butt the last time I tried it).
They've answered why Dart many times. It's a language that fits their needs, since it has JIT, AOT, compilation to JS and now WASM. Back then there weren't many languages that could do all that, and even today there aren't many. Kotlin (and other JVM languages) and TypeScript (and other compile-to-JS-only languages) are already out since they are not AOT, only JIT even now.
More importantly, it was a Google language that they could mold for their own needs, not so possible if it's an outside language like TypeScript. For example, early on, they asked the Dart team to create an AOT compiler since Apple does not allow JITted code apparently (not sure how React Native gets around this then), or maybe it didn't back then, and the Dart team was able to do it successfully for the Flutter team. Try asking the TypeScript team to do the same, it's next to impossible.
For what it's worth, Dart 3+ introduces more functional parts like records, patterns, and exhaustive pattern matching so you can use it in a functional style if you want once that ships. There is also fpdart, for full functional support, and for brevity of code, since Dart has the ability to generate code via macros (with build_runner), you can also use packages like functional_widget, flutter_hooks etc to achieve a very functional code style as well, React-like.
This is a great podcast/video episode on how Flutter came to be, from the early days to now, and how it used JS in the beginning but it didn't serve their needs, as well as how it used to be more imperative until a declarative React-like model was then made.
> since Apple does not allow JITted code apparently (not sure how React Native gets around this then)
With React Native you have two options. Use Apple's own JavaScriptCore engine which has special JIT permissions, or use Meta's Hermes engine which runs as a bytecode interpreter.
In either case you can always drop down to native code (Swift/Objective-C (iOS), Kotlin/Java (android), or C/C++ (any platform)) which can be used for anything compute heavy.
No, the ability to JIT is not per framework (I'm unsure how that would work?), it's per process. Using JSC doesn't give you a JIT - now the JSC interpreter is very fast, so it's possible claims that they "need JIT" are incorrect (back when I worked on JSC it was a common belief from people that the JITs were magic fairy dust, and so would come in to anything with a data-less assumption that a JIT was needed), it's also possible that "react native" is using wkwebview in which case the content would be running in a separate web content process with a jit.
I don't think React Native is using WkWebView. But that the introduction of WkWebView which allows JIT was the source of my confusion. I was under the impression that JIT was enabled for any uses of JSC in iOS at that time. But it seems that is not the case.
So the situation with React Native is that you can either use JSC, Hermes (or I believe V8 in jitless mode). All of which are interpreters. On Android you can of course use JIT (with either JSC or V8).
Sure, not ten years ago though when it was first starting. Doesn't Jetpack Compose work similarly to Flutter in that it draws every pixel? If so, Kotlin native could be used there to bring it to web and desktop perhaps.
Java, again, is not ahead of time compiled, or at least did not have a good solution for that ten years ago. Even Android apps now run as AOT compiled apps with Android Runtime (ART), discontinuing the Dalvik VM.
The fact that Excelsior is dead probably says something.
There are AoT compilers for Java, but I'm not aware of any successful widely-used ones. Java and the Java ecosystem rely pretty heavily on class loaders and reflection which make AoT compilation very difficult. Java in its bones is designed to be a JIT VM language and you'll always be going against the grain if you try to statically compile it.
Dart was also initially designed to be a JIT VM language (by the same folks who made the HotSpot JVM) but without many of the pitfalls in Java that make AoT hard, and over time we have deliberately evolved the language (in breaking ways!) to make it much more amenable to static compilation.
Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others.
GraalVM native is quite a big thing nowadays, and reflection is not really a problem for AOT, class loading is more so, but that is easily solvable by assuming a closed world (the way Graal does it). So you just simply list all the classes you plan to reflect on/load and that’s it.
> Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others
Sure, but I don’t claim to replace SQL or Prolog with Java, but a regular old managed language which has zero unique features that would give it a reason to exist.
> More importantly, it was a Google language that they could mold for their own needs, not so possible if it's an outside language like TypeScript. For example, early on, they asked the Dart team to create an AOT compiler since Apple does not allow JITted code apparently (not sure how React Native gets around this then), or maybe it didn't back then, and the Dart team was able to do it successfully for the Flutter team. Try asking the TypeScript team to do the same, it's next to impossible.
Why would you need to modify the language? Dart is the most basic managed language without any novel feature. There is zero reason why, say, java couldn’t have been fitted for this particular niche.
How will you convince the Java team to add things you want to make it work better for your framework? You could try adding them yourself but you'd be forking and making your own Java dialect at that point. They did that instead with Dart which they own.
What would you need for a framework that can’t be implemented as a library? Will we recreate every language from scratch for the next logging, gui lib, web framework as well?
For example, making an AOT compiler. Or adding other features. Or making the implementation more suited to client side apps. There are many things you can do to a language to make it easier for a specific use case. In the extreme, this is what DSLs are.
I don't understand why you don't understand that having first class control over a language's development is a useful thing to have.
All else being equal, it is still useful to have control over a language's development. It doesn't matter that Dart may or may not have features not present in other languages, as long as they can add them as necessary based on Flutter's development.
I’m not sure why the Dart hate honestly. It’s a pretty solid language in my opinion and I like the direction they’re taking (non-nullable, record, pattern matching). The ecosystem is weak for sure, but that’s not a gripe on the language itself.
I’m curious what do you dislike about it apart from semi-colons and the constructor syntax (which seem fine to me?).
Okay I guess I should provide more details. Constructor syntax fine? Jesus how come you can't use the constructor parameters as the default values but have to either resort to using `late` or that weird `: {}` after constructor like in C++, can't remember how it was. I just added `late` and thought whatever. Probably there are nuances I've missed but how come you had to reinvent that - thought it should be intuitive from the get-go.
While stating itself to be statically typed you can also shoot yourself in the foot by simply using `as Type`, similar to TypeScript. Because that just assigns it to a type and doesn't cast it like you do it in say Rust.
The extreme use of classes with `abstract class` and whatnot feels kinda 90's to me, just a lot of abstractions and for what? Just feels unnecessarily complicated for something seemingly simple.
Maybe it's just little too enterprisey for my taste. Maybe that's it. I'm glad they are taking steps to improve it, I think making it more functional would help it. Even just to distinguish it from the other OOP languages.
And how come simple state management seemed so difficult as well? I tried using my tried and true MobX which is implemented for Dart as well but was disappointed in its complexity and the fact it requires you to run a code generator to wrap your classes with observables. What? Insane.
> Jesus how come you can't use the constructor parameters as the default values but have to either resort to using `late` or that weird `: {}` after constructor like in C++, can't remember how it was.
This is a really good question. The reason is that it ensures that you can never see a field before it's initialized. In Java, you might think that you'll never observe a final field before it's been initialized but not so! In the constructor, you can call a method on `this` even before all fields have been definitely initialized. Inside that method (which might be overridden!), you can then read the field. It will be default initialized.
This means every time you create an object in Java, some extra code is running to default initialize all the fields just in case they get read before they're actually initialized. (I assume in some cases the compiler can prove it's not needed and eliminate it, but not in the general case).
It also means that the type system can't rely on fields being initialized for static safety. That in turn means that the compiler can't optimize based on that fact.
In Dart with the constructor initialization syntax, it's not syntactically possible to access any state on a new instance until after every single one of its initializers has run. That means that, in concert with null safety, if you have a non-nullable field, the compiler knows it will never ever be null and then can generate smaller, faster code based on that guarantee.
I agree the constructor initializer syntax is annoying and I wish we had something better, but it's there for a reason. Also, in practice, you often use `this.` or `super.` on the constructor parameters and avoid the initializers entirely.
> While stating itself to be statically typed you can also shoot yourself in the foot by simply using `as Type`, similar to TypeScript. Because that just assigns it to a type and doesn't cast it like you do it in say Rust.
An "as" expression is fully sound and will throw a runtime exception if the value isn't a valid instance of the cast type.
> The extreme use of classes with `abstract class` and whatnot feels kinda 90's to me, just a lot of abstractions and for what?
You don't have to use classes if you don't want to. You can define functions and variables all at the top level and write in a completely procedural or functional style if that's your jam. Some of the Dart packages I maintain are mostly functions.
> I think making it more functional would help it.
We're getting there. It's always had anonymous functions, closures, and plenty of higher-order functions in the collection API. We're adding pattern mataching and exhaustiveness checking now which should let you program in an algebraic datatype style.
Exactly, after JVM world I'm especially loving reified generics. Being able to access type information on generics at runtime is very helpful. Plus developer experience for working with DartVM and Flutter is crazy good.
It gets the hate because it comes from Google and it was originally marketed as a JavaScript replacement.
Additionally, the first unoptimized compiler resulted in "hello world" having a gargantuan amount of JavaScript code. That left the language with a hard to shake stigma.
To be fair, around a decade ago, Chrome wanted to add a Dart VM (Dartium) to which many vehemently protested, and I agree it would have been a bad move to have a browser essentially have its own language rather than JS, forcing other browsers to adopt it. From there though, we got a much better cross browser standards-based solution in the form of WASM, which is even more powerful since languages other than Dart could be used. This controversy is where I first saw the Dart hate, but it has grown into a nice language since, especially with Dart 3+ which introduces, records, patterns, and exhaustive pattern matching.
Is that not just string/int/basic types? Last time I looked it was and it was a complete joke.
I want to define
enum UserState {
case loggedOut
case loggedIn(user: User)
}
where User is itself a struct with props like email/id/Etc
Then, I want to be able to switch on said enum, so that my code can take a UserSession state stream and switch over each case to react accordingly. This gives me compiler - enforced case handling completeness everywhere my enum is consumed which is amazing for code reliability.
This is trivial in Swift or any real language, but with Dart and the stupid flutter bloc model you seemingly can’t do this and end up with these huge if cast chains to send messages.
If I’m wrong and things have changed for the better please let me know, it was my biggest issue with dart/flutter
I think you give Dart too little credit. Consider the other popular languages of today - Python, JavaScript, C++. Dart is far nicer than those. I'd say it is nicer than Go too.
I'm not sure what you mean about boilerplate. The way you create UIs in Dart is one of the main draws of Flutter. Would you rather Android's XML? Or QWidget?
The language design is not an issue with Flutter. Flutter's issues are mainly ecosystem size and performance.
Usually, it's a sign that you refactor something to a separate StatelessWidget or at least a function.
If you're coming from web dev, you will be used to having all this container, padding, center, column code in CSS. Now you have it in UI. But on the flip side, this has its flexibility. You can usually refactor the styling part out of the actual widget if you want.
For me the big problems with flutter are state management and platform interop. Yet it's nicer than most other options for developing UI.
To be fair it’s not a bad choice for UI: supporting both AOT and JIT speeds up the dev loop and allows compiled performance + hot reloading in dev, which is good for UI development.
Considering that Dart was made to run in browsers, they did in fact.
The APIs the OP are complaining about are Flutter's not Dart's. Flutter tried to do a vdom-like thing that also included styling on top of regular function call syntax and it is... what it is.
The style of writing the UI code takes some time to get used to, but the composability is really nice. For example, if I want to center something, I use Center and it works as I predicted. If I want to change the opacity of something, I don't need to find the opacity property of a particular widget, I can just...use Opacity, and it'll work for everything.
This style is a way to have (extreme) composition over inheritance, which apparently was very useful for the framework authors who mentioned that they didn't need to keep reimplementing opacity for example for every single widget.
You can use Flutter as an imperative framework. Just ignore widgets (the reactive top layer of Flutter) and use the underlying imperative elements directly.
Well, I'd say the main value proposition of Qt/Delphi/wxWidgets/WinForms/etc... is a rich set of widgets/controls including its event handling and layout mechanisms. Is such stuff available in the imperative impl of Flutter?
> Idk, you'd think an org like Google had the resources and the talent to make something truly amazing
One would think that, which is why I struggle to believe Google is really invested in Flutter's success. They keep it alive and talk about it, but I wonder how much they actually care about it.
Here are some updates from our side:
1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!
2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw
Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!