Flutter desktop isn’t there yet(plei.one)
plei.one
Flutter desktop isn’t there yet
https://plei.one/blog/flutter-desktop-not-there-yet/
239 comments
First of all: Thank you for your outstanding work!
And sorry to ask this here, but how have the recent layoffs affected the flutter team?
We're using flutter as our main framework for our app and it's quite important.
The layoffs have sparked some fears that flutter development might slow down.
And sorry to ask this here, but how have the recent layoffs affected the flutter team?
We're using flutter as our main framework for our app and it's quite important.
The layoffs have sparked some fears that flutter development might slow down.
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.
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.
You’re supposed to feel better, not ask questions. Besides they won’t say anything that affects their own job security (nor should they imo).
> Flutter is a community project
A quick WHOIS search for flutter.dev and pub.dev domains tells me that this is not really the case.
A quick WHOIS search for flutter.dev and pub.dev domains tells me that this is not really the case.
[deleted]
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.
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".
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.
And I'm not going to contribute any change, no matter how small, to a project whose maintainer reserves the right to change the license in the future.
Why is your project changing the license, and why do you assume that contributors would still have done so under whatever license you're changing to?
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.
As a contributor I wouldn't want the code I made to be under a different license in the future.
Thank you! That's reassuring and I strongly believe that Flutter is the best option for developing cross platform apps right now.
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.
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.
Is Flutter open source?
Yeah it is under a BSD license:
https://github.com/flutter/flutter
https://github.com/flutter/flutter
It's open source the way Chrome is open source: the source is there, but the development is ~100% by Google
Google Chrome is not open source, Chromium is.
[Reference](https://en.wikipedia.org/wiki/Chromium_(web_browser)#:~:text....)
[Reference](https://en.wikipedia.org/wiki/Chromium_(web_browser)#:~:text....)
People keep pointing this out as if this made a grain of difference.
Not 100%, at least 30% of PRs are done by outside Google contributors.
How relevant are those PRs to the actual development of the product?
That is, fixing minor bugs or translation strings vs adding new web APIs etc.?
That is, fixing minor bugs or translation strings vs adding new web APIs etc.?
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!
Last time I used flutter for desktop, setting custom window size required an external package. I think it's a significant use case for many people.
Agreed! We will add support for window customization as part of the multi-window effort.
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?
Please check the contribution guide: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....
We strive to be an open community. Anyone can become a Flutter team member if they contribute frequently :)
We strive to be an open community. Anyone can become a Flutter team member if they contribute frequently :)
Thank you! I think that's a great attitude and a key to the long-term success.
We've got a guide here that covers some of these areas: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....
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...
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...
Hi there, I have been a happy flutter user for quite some time now, keep up them good work!
Same, contrary to some of the comments here I’ve had nothing but great experiences coming from a purely web background previously.
same here,keep up the great work.
by the way dart is my favorite cross platform language nowadays beyond flutter.
by the way dart is my favorite cross platform language nowadays beyond flutter.
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.
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:
https://github.com/dart-lang/language/blob/master/working/au...
I'm glad you're enjoying Dart!
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:
https://github.com/dart-lang/language/blob/master/working/au...
I'm glad you're enjoying Dart!
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 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":
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'
dart_build ()
{
[[ -f pubspec.yaml ]] || return;
DART=$(grep ^name pubspec.yaml | awk '{print $2}');
dart pub get;
dart compile exe bin/"$DART".dart
}dart is my favorite cross platform language nowadays beyond flutter
Yeah, it's very underrated. I find it nearly as expressive as Python with far better maintainability and performance.
Yeah, it's very underrated. I find it nearly as expressive as Python with far better maintainability and performance.
That's great to hear! When I get the chance, I'll update the article to note that custom context menus are actually supported now.
Is impeler going to affect (in good way) the performance/latency on desktop too? (I think it's mostly for iOS now, right)?
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
You can learn more about Impeller here: https://www.youtube.com/watch?v=gKrYWC_SDxQ
You can learn more about Impeller here: https://www.youtube.com/watch?v=gKrYWC_SDxQ
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?
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?
There are a lot of levels of indirection here:
* A video on YouTube...
* Of a livestream...
* 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.
* A video on YouTube...
* Of a livestream...
* 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.
On the one hand, ok... sure... on the other:
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.
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.
The plan AFAIK is to make it the default everywhere but they are just rolling out each platform in some kind of prioritised order.
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."
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."
Well it seems there are 11K open issues and 66K closed issues in their github page.
So maybe some issues got fixed at least?
So maybe some issues got fixed at least?
The dreaded, 'closed due to inactivity' strikes again.
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).
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).
This is why dogfooding is extremely important. You want the people making the reams to feel those 1000 papercuts.
Agreed, still unable to take a high res photo from any device using their own camera plugin.
https://github.com/flutter/flutter/issues/58163#issuecomment...
Sighhh. Maybe one day.
https://github.com/flutter/flutter/issues/58163#issuecomment...
Sighhh. Maybe one day.
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.
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 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.
> Users do not necessarily care if the application looks pixel perfect
They do care. They just don't know the words "pixel perfect".
However, everything is an improvement over the standard state of corporate UIs
They do care. They just don't know the words "pixel perfect".
However, everything is an improvement over the standard state of corporate UIs
[deleted]
> 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?
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.
Flutter just recognises that.
Flutter just recognises that.
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.
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.
I thank the flutter team very very much for not using JS. We're already overflown with this stuff and a bit of variety and competition cannot hurt.
I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome
I personally dislike the whole JS ecosystem with a passion, and feel I'm not alone in this, so having an alternative is warmly welcome
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.
Odd thing to say, since you definitely have to set up a Flutter/Dart development environment—you don't just get it for free.
The only real way to escape this at all is to settle on the browser as your runtime, so there's a certain irony to what you're saying.
The only real way to escape this at all is to settle on the browser as your runtime, so there's a certain irony to what you're saying.
I never said we didn't have to set up an environment, but that the environment is
1. Installing Flutter 2. flutter create 3. flutter run
Instead of installing/configuring/setting-up npm, typescript, eslint + rules, react + rules + types, prettier, react-native-web + rules + types, a rendering framework + rules + types, webpack, jest, and whatever else.
You do, basically, get it for free.
1. Installing Flutter 2. flutter create 3. flutter run
Instead of installing/configuring/setting-up npm, typescript, eslint + rules, react + rules + types, prettier, react-native-web + rules + types, a rendering framework + rules + types, webpack, jest, and whatever else.
You do, basically, get it for free.
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)?
1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
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)?
1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-java...>
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.
And yes, it's still (basically) free.
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.
And yes, it's still (basically) free.
> 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.)
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.)
> I personally dislike the whole JS ecosystem
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
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 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.
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.
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.
Someday maybe they can switch the embedding shells to not draw but instantiate the native controls. That'll be really game changer.
This attempt to draw every single control is too much effort with apparent inconsistencies.
This attempt to draw every single control is too much effort with apparent inconsistencies.
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.
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.
That's nice if you have the funds and time for that. Fully native is ideal.
But I don't agree cross-platform can't feel "right". Flutter's approach it can't. React Native's it can. Qt vs WxWidgets all over again.
If I had to duplicate my codebase for each platform and learn each IDE/language just to continue my app, it would never exist.
I solely created and maintain the iOS app, the Android app, and the web app for my company and for my side projects thanks to React Native.
I can extend any native api or view, I can learn middle out for each platform.
I can abstract and swap out any file or conditionally style based on platform.
I developed the web app first using React Native Web. It took me a month to get the iOS and Android app released to the store.
No Ionic or web wrapper crap needed... The one thing is getting the React stack and tooling just right.
So it's Expo or devote quite a bit of time in the beginning to your stack.
But I don't agree cross-platform can't feel "right". Flutter's approach it can't. React Native's it can. Qt vs WxWidgets all over again.
If I had to duplicate my codebase for each platform and learn each IDE/language just to continue my app, it would never exist.
I solely created and maintain the iOS app, the Android app, and the web app for my company and for my side projects thanks to React Native.
I can extend any native api or view, I can learn middle out for each platform.
I can abstract and swap out any file or conditionally style based on platform.
I developed the web app first using React Native Web. It took me a month to get the iOS and Android app released to the store.
No Ionic or web wrapper crap needed... The one thing is getting the React stack and tooling just right.
So it's Expo or devote quite a bit of time in the beginning to your stack.
> Qt vs WxWidgets all over again.
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.
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.
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.
The story on desktop is a little better but the same principle applies to some degree.
I’m shocked they’re still using Dart. Even if Dart is good, it’ll still be what prevents flutter from being widely adopted
It's an obvious area for a PR boost if the chips are looking down.
I can see the HN headline now...
"Rust support added to Flutter [34,432 karma]"
I can see the HN headline now...
"Rust support added to Flutter [34,432 karma]"
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.
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
Anything else is for hobbyists.
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
Anything else is for hobbyists.
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
You only need to look to SwiftUI to realize that this is false.
SwiftUI has a lot of problems, but Apple has done great work building components and paradigms that adapt to the target device.
For example, check out how forms are defined: https://developer.apple.com/videos/play/wwdc2022/10052/
Defining an interface this way saves time for developers and provides consistency to users who use apps across different devices.
SwiftUI has a lot of problems, but Apple has done great work building components and paradigms that adapt to the target device.
For example, check out how forms are defined: https://developer.apple.com/videos/play/wwdc2022/10052/
Defining an interface this way saves time for developers and provides consistency to users who use apps across different devices.
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.
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.
What are you using to do the rust bindings?
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.
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.
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.
Last year, I built a desktop app with Flutter with native-looking UI, for both macOS and Windows: https://blog.whidev.com/native-looking-desktop-app-with-flut...
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.
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 AdWords is made with Dart, specifically AngularDart, not Flutter.
Edit: yes, Google Ads the mobile app is made with Flutter.
Edit: yes, Google Ads the mobile app is made with Flutter.
Sorry I was referring to the mobile apps not the web experience.
Where does it show that the mobile app is in Flutter?
Under the settings screen there is a software licenses section. In there.
Neat, it says Powered by Flutter on Android. That's pretty cool.
You realize that even Google doesn’t use Flutter in their cross platform consumer apps.
https://9to5google.com/2021/10/10/google-ios-apps-native/
And just because “mega sized players” are betting on it has never stopped Google from abandoning projects before.
https://9to5google.com/2021/10/10/google-ios-apps-native/
And just because “mega sized players” are betting on it has never stopped Google from abandoning projects before.
> 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?
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?
Google Ads is written in Flutter - https://play.google.com/store/apps/details?id=com.google.and... - if you go download, skip the welcoming bits, and go to licensing you'll see lots of flutter libraries including flutter itself
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.
> the Ads app is the same as AdWords on web
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.
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.
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.
Both having common Dart code, although not common UI is probably still good win for a lot of things.
[deleted]
> Google’s single biggest money maker Ads is built with it.
If Flutter disappeared tomorrow nobody would even notice it. How much functionality do you think is there?
If Flutter disappeared tomorrow nobody would even notice it. How much functionality do you think is there?
In March 2021 there were 150 thousand Flutter apps in Google Play store.
In May 2022 - 500 thousand.
See: https://www.nomtek.com/blog/flutter-app-examples
Today: I'm too lazy but you can google for more up-to-date stats.
"nobody" is gigantically wrong.
Flutter is extremely popular in mobile.
Web and desktop support is behind but it'll improve and popularity of Flutter on desktop and web will grow too.
In May 2022 - 500 thousand.
See: https://www.nomtek.com/blog/flutter-app-examples
Today: I'm too lazy but you can google for more up-to-date stats.
"nobody" is gigantically wrong.
Flutter is extremely popular in mobile.
Web and desktop support is behind but it'll improve and popularity of Flutter on desktop and web will grow too.
I meant in Google Ads. How much is the front end there anyway?
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.
Wait till you hear about Kivy. It's a hard, decade+ long slog to get this right.
To be fair, Flutter is now a close second to React Native, which is 7 years old.
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).
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 :)
This. This was one of the reasons we ended up abandoning Flutter (the state of text editing was the other, super_editor notwithstanding).
Haven't used, but seems to be available as a community package:
https://pub.dev/packages/desktop_webview_window
Edit: on 2nd glance perhaps this doesn't embed into the widget tree but is always its own window?
https://pub.dev/packages/desktop_webview_window
Edit: on 2nd glance perhaps this doesn't embed into the widget tree but is always its own window?
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.
I tried it, it's quite snappy compared to Electron, I assume because it's AOT compiled.
Probably moreso avoiding the DOM, Javascript JITs are very fast.
Multiple windows is on the roadmap and high priority.
For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.
For me the best use of desktop is testing mobile apps without having to use my phone or an emulator. It works really well.
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.
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.
Ages indeed. And how sad and frustrating. The best cross-platform app framework is one that I used in 1990.
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.
See https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g... for an overview of UI libs in Rust.
See https://www.cmyr.net/blog/gui-framework-ingredients.html for a great overview of some of the challenges making a GUI library
See https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-g... for an overview of UI libs in Rust.
See https://www.cmyr.net/blog/gui-framework-ingredients.html for a great overview of some of the challenges making a GUI library
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.
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?
I really don't understand these priorities.
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?
I really don't understand these priorities.
Not surprising.
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?
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?
Probably this one https://rive.app/
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
https://pub.dev/packages/platform_ui
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
https://pub.dev/packages/platform_ui
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.
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.
i am greatful for Flutter if only to motivate the React Native team
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.
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.
Indeed, as a solo developer, Flutter is a godsend to be competitive with others in the market who already have integrations with a bunch of platforms.
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 can see some apps needing to be native (ex: using AR/ML libraries where you need to squeeze everything out of the phone)
I agree but all that's needed there is an escape hatch with some way for the non-native interface to interact with the native code.
I agree but all that's needed there is an escape hatch with some way for the non-native interface to interact with the native code.
Not being troll-y, but …
NOTHING IS THERE YET
“There” is Utopia.
“There” is a language being ergonomic, ubiquitous, fast and with libraries that are awesome!
That is too much to expect.
NOTHING IS THERE YET
“There” is Utopia.
“There” is a language being ergonomic, ubiquitous, fast and with libraries that are awesome!
That is too much to expect.
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 think the guys at Rive would disagree with this sentiment. https://twitter.com/FlutterDev/status/1288494688115126273
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.
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.
> The Flutter team should consider unpegging from dart and utilize JavaScript/Typescript, Kotlin, or Swift.
why would they do that, dart is better than all those languages except for maybe swift.
why would they do that, dart is better than all those languages except for maybe swift.
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.
I feel like this is similar the conversations we heard about Rust and Go 5-10 years ago.
late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.
late edit: 5-10 years ago people were complaining about these languages having issues binding databases, network protocols, etc.
Do Rust and Go have good (complete) Desktop UI libraries yet?
I don't know about Rust but Go doesn't.
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.
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.
There is react native. Facebook pays for Android/iOS and Microsoft pays for Windows/macOS.
Sadly no maintained Linux desktop app support.
Sadly no maintained Linux desktop app support.
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.
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.
For Rust, the existence of https://www.areweguiyet.com/ suggests "no".
not at all
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.
Hello, I'm from the Flutter desktop team. We're actively working on Windows ARM64 support, this should be coming soon! Stay tuned :)
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.
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.
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.
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.
The fact that it happens to fit your limited needs doesn’t mean that it’s suitable for general desktop development.
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.
Flutter Desktop isn't the right environment for you.
I guess I'm thinking of Flutter's desktop support in relation to how it is on mobile. Flutter mobile does have a lot of built in stuff.
I don’t know. I have a colleague who swears by it.
2 cents from Sciter developer...
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.
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).
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.
https://www.youtube.com/watch?v=xqGAC5QCYuQ
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.
https://www.youtube.com/watch?v=xqGAC5QCYuQ
> 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.
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).
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).
> 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.
There is Kotlin Native now.
There is Kotlin Native now.
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 fits all the bills and Google already has ample experience/tooling working with it, including a very great java to js compiler.
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.
Java had AoT compilers for more than 20 years, https://en.wikipedia.org/wiki/Excelsior_JET
If Google really wanted they could have wrote one.
If Google really wanted they could have wrote one.
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.
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.
> 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.
> If Google really wanted they could have wrote one.
Which they did, but for Dart instead.
Which they did, but for Dart instead.
Which has zero ecosystem and just reinventing the wheel.
> 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.
Replace TypeScript with Java above.
Replace TypeScript with Java above.
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.
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.
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?).
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.
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.
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.
Thanks for the detailed write up!
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.
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.
Oh yeah I do remember that. I can see how some of that stigma lingers.
Last I checked you can’t even have enums with payloads/ associated values.
Garbage language
Garbage language
You can since 2.17. Not sure if you’re being sarcastic about this making it a garbage language.
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 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
See my sibling comment. That appears to only work with basic types like strings/ints?
I need to add complex objects, sometimes multiple. Swift lets you do this easily.
I need to add complex objects, sometimes multiple. Swift lets you do this easily.
No, you can add as many fields of whatever types you want to an enum in Dart.
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.
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.
Declarative UI has arrived on Android via Jetpack Compose. So there is no need to create new UI in XML anymore.
The abiliy to share the codebase between platforms is much bigger draw rather then the way that the UI is written.
The abiliy to share the codebase between platforms is much bigger draw rather then the way that the UI is written.
> (Center here, Container there)
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.
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.
They didn’t create Dart for UI. It was dead and they shoehorned it into Flutter.
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 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.
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.
Yeah it was an attempt to fix JS before JS improved a lot in recent years, and before TS took off.
> so much boilerplate feeling code (Center here, Container there)
That's Flutter, the framework. I like Dart and I wish some conventional imperative Qt/Delphi-like GUI toolkit was available for it.
That's Flutter, the framework. I like Dart and I wish some conventional imperative Qt/Delphi-like GUI toolkit was available for it.
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?
Center here, Container there
Is that really determined by Dart and not by how Flutter chooses to do things?
Is that really determined by Dart and not by how Flutter chooses to do things?
No you're right, it's Flutter, they are misconstruing Dart and Flutter.
True, just have a look at Stack Overflow questions tagged Dart, very few (being extra cautious here) are not flutter question.
https://stackoverflow.com/questions/tagged/dart
https://stackoverflow.com/questions/tagged/dart
To be fair, looking at Kotlin would likely yield similar results, being mainly used for Android.
> 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.
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.
[deleted]
kid-icarus(1)
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!