Flutter 3(docs.flutter.dev)
docs.flutter.dev
Flutter 3
https://docs.flutter.dev/whats-new#may-11-2022-google-io-edition-flutter-3-release
452 comments
I have been developing in Flutter for a few years now, and I really enjoy the ecosystem. It is the only mobile development environment I have every really enjoyed using.
When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment.
As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages.
In my experience, Flutter is a great environment for getting things done with limited resources.
When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment.
As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages.
In my experience, Flutter is a great environment for getting things done with limited resources.
Is the Web version of Flutter still using canvas? I tried it a while back and it was just a canvas rendering everything. That makes SEO impossible. It's also useless for accessibility/screen readers. Please correct me if I am wrong.
The answer to both of these things is the accessibility object model.
You weren’t wrong historically but you aren’t right currently.
Flutter web including the canvas rendering option has proper accessibility as of today AFAIK.
You weren’t wrong historically but you aren’t right currently.
Flutter web including the canvas rendering option has proper accessibility as of today AFAIK.
I'm curious if anyone can comment on their experience using the HTML renderer.
Very slow. Not yet ready for production.
I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.
> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages.
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
This might not be obvious in anyway if you’re not pretty deep in the Dart ecosystem but I’ve never seen anyone pay as much attention about building a good long term language as that team.
They put crazy amounts of thought and effort into how they evolve it.
Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it.
Then they built a bunch of really nice tooling and DX on top of it.
It’s genuinely a pleasure to work with in my experience.
They put crazy amounts of thought and effort into how they evolve it.
Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it.
Then they built a bunch of really nice tooling and DX on top of it.
It’s genuinely a pleasure to work with in my experience.
I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/
The incentive structures around technical books are pretty weird.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
Former O'Reilly editor here: story checks out. The 1/3 might be a bit low -- I had some surprises (one guy joined the Peace Corps and moved to South America, plus usual divorces and deaths and job changes) but it felt more like 80% completed. This might be the rosy glasses of memory, though.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
That is fascinating. As someone who has writing a technical book as a life goal, I'd love to ask--do you have any insights you'd be willing to share regarding how to get started?
Pick a topic you know a lot about, or are willing to learn a lot about. Start writing.
Are you already blogging? If not, I would start doing that. Writing short form technical articles and sharing them is like bootcamp for longer form writing. You'll learn the mechanics of organizing thoughts into a linear narrative, the discipline to finish, and you'll get feedback from readers about what works and what doesn't.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
Alternative to (3) - Company that owns a language and is willing to pay decent money for someone qualified to write a book in order to increase popularity
Yeah, this is viable, but the cost is quite high if you're paying a skilled software engineer for their time. The company driving the language can probably spend that budget better elsewhere. (For example, on online documentation that is more easily incrementally maintained and grown.)
Picking it up is really easy if you have any experience with Java or C# and the QOL improvements compared to the former make it seem like a treat for me. What language are people who hate it coming from?
[deleted]
> Flutter is the only realistic option for true cross platform UIs that run everywhere.
I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way.
You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?
I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way.
You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?
I have yet to see a world in which local file access, background services, local notifications, timers, alarms, native media controls, etc, works as well on web as in native apps. A lot of it is there "in theory", but web tech has the achilles heel of only allowing stuff that would be safe to have in a random website that some asshat links you on twitter.
Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
“Everything” working in a web app is unlikely to happen any time soon. The security model is so different, though less different between mobile and web than mobile and desktop. Also the Apple/Safari ecosystem is the new IE and dragging down some of the innovation.
However, I believe it might not matter. 95% apps can be done as web apps today, especially what comes to boring business applications. 5% we can wait for some time.
What comes to Flutter, it can never integrate well within a browser as it sufferes from the same issue as Java applets. It does not use the web browser native rendering engine and widgets will always feel kludgy, have accessibility issues and so on. Not a big deal for some apps like games. And Google Docs is already using Canvas based rendering so seems like Flutter canvas based apps might have hope.
However, I believe it might not matter. 95% apps can be done as web apps today, especially what comes to boring business applications. 5% we can wait for some time.
What comes to Flutter, it can never integrate well within a browser as it sufferes from the same issue as Java applets. It does not use the web browser native rendering engine and widgets will always feel kludgy, have accessibility issues and so on. Not a big deal for some apps like games. And Google Docs is already using Canvas based rendering so seems like Flutter canvas based apps might have hope.
> And Google Docs is already using Canvas based rendering so seems like Flutter canvas based apps might have hope.
Well, isn’t it the Java applets model as you call it as well? But is a colored div that much better of a button?
Though I don’t disagree with you, indeed most apps can be web-based.
Well, isn’t it the Java applets model as you call it as well? But is a colored div that much better of a button?
Though I don’t disagree with you, indeed most apps can be web-based.
That plumbing is there and easily doable, but up to Apple… just like how the proliferation of QR codes in America didn’t happen until Apple decided to include it in the camera app. It (QR codes) was widely used for maybe almost a decade in China due to inclusion in the ubiquitous Wechat app.
However given the app store is a cash cow for Apple I highly doubt they’d want to integrate web more deeply.
However given the app store is a cash cow for Apple I highly doubt they’d want to integrate web more deeply.
Notifications is the main one which is still missing (at least on iOS, not sure about android). If notifications are possible for websites, then it would make web dev so much better for vast majority of apps.
Local storage already does a lot of needed data storage (though apple has recently made this complicated with their auto delete after certain period). Local file access for uploads is also now possible on iOS using the Files app.
Local storage already does a lot of needed data storage (though apple has recently made this complicated with their auto delete after certain period). Local file access for uploads is also now possible on iOS using the Files app.
You have yet to see a world where people update their beliefs more than once per decades. Hybrid native web apps are trivial, see e.g. Ionic capacitor plugins
I'm well aware of hybrid apps and Ionic. I wouldn't call those solutions properly "web" though. They're basically only using web tech as a presentation layer, and deferring to native plugins to do the heavy lifting when required. Very similar to how Flutter does it.
So if your claim is simply that CSS/HTML/JS is capable of creating good user interfaces, I'm not arguing against it.
So if your claim is simply that CSS/HTML/JS is capable of creating good user interfaces, I'm not arguing against it.
> a presentation layer, and deferring to native plugins to do the heavy lifting when required
bruh it's not just UI, the JS/TS code is where the business logic code is. And anyway the UI is the whole point, we are debating UI libraries. But most importantly native plugins are niche, you use them very rarely and for very specific needs, they occupy generally less than 1-5% of the code base. e.g. when you need to access the camera or sensors, which you usually don't need and most apps don't actually benefit from plugins. I'm not even talking about the fact that most of those niche needs are generally covered by equivalent modern web APIs (e.g. web share) but since plugins are trivial to use, people often use them even when a web api already exist.
bruh it's not just UI, the JS/TS code is where the business logic code is. And anyway the UI is the whole point, we are debating UI libraries. But most importantly native plugins are niche, you use them very rarely and for very specific needs, they occupy generally less than 1-5% of the code base. e.g. when you need to access the camera or sensors, which you usually don't need and most apps don't actually benefit from plugins. I'm not even talking about the fact that most of those niche needs are generally covered by equivalent modern web APIs (e.g. web share) but since plugins are trivial to use, people often use them even when a web api already exist.
This 100%. Also, Flutter Web is still pretty much an abomination (right now), IMO. Sure, it "works". So did Flash. (edit: Just wanted to add, I love Flutter for mobile, even think desktop might work. Just don't think it's for web. Maybe for very specific app types.)
>"The web is the cross platform"
Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
> The web is the cross platform that runs everywhere (as in in a browser or webview).
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
I may have very different uses for my PC than you (I use it primarily for gaming and my job as a game developer), but I find the notion of having to upgrade your PC to run a browser-based application very strange.
I am not saying that electron-based apps are generally good or efficient. Most of them are frustratingly slow and awkward. But this inefficiency rarely seems to be constrained by local resources: the apps often stand still, consuming barely any resources (CPU time, memory, etc.) and taking ages to load each page. At the same time you can often visit the same page in Chrome and it will load almost instantly.
It is frustrating and I have no idea what is going on, but it doesn't seem like upgrading the PC would solve the issue.
I am not saying that electron-based apps are generally good or efficient. Most of them are frustratingly slow and awkward. But this inefficiency rarely seems to be constrained by local resources: the apps often stand still, consuming barely any resources (CPU time, memory, etc.) and taking ages to load each page. At the same time you can often visit the same page in Chrome and it will load almost instantly.
It is frustrating and I have no idea what is going on, but it doesn't seem like upgrading the PC would solve the issue.
I came here to say this too. Build your app as a website, then just use a simple browser window of an app that loads your site. Then you only develop in one place, and have nothing to compile or build. Hardly ever have to update your "app" builds even. This won't replace every app of course depending on what you're trying to do and if it requires specific hardware features, but I'd say about 99% of apps don't need to be native.
This is also how you lose customers.
Why? Amazon did this, back in the day, not sure how they do it now.
I get the feeling most the Amazon app is still webviews today
If done properly your customers won’t even know.
> The web is the cross platform that runs everywhere (as in in a browser or webview)
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
Interesting, I've had the opposite experience. I'd love to develop in native with something like Flutter or React Native, but I find CSS to be much easier and more flexible to use. The base components always /seem/ flexible enough until I want to do something visually complicated like add an animation that blurs an image on hover. I know CSS is horrendous in consistency, but it's piecemeal development has led to it having every UI feature I could really want/need now that I've paid the price and met its learning curve.
For what it’s worth CSS is all I knew prior to Flutter so the learning curve was a bit weird initially but once you start matching concepts you already know like Flutter also has “flexbox” for example it was pretty easy from there. Also having a strongly typed language with great docs is a huge help.
I wish this were true, but in my (admittedly limited) research I'm not sure it is.
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
[deleted]
Other than what sibling comments said, I have to add that flutter is much more approachable for new developers than web is. Most widgets are built-in, and development workflow is also simpler. This is what I heard from college students.
"I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages."
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it.
After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now.
The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb.
The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
I think that's pretty short-sighted. Dart is hardly an esoteric/niche language like Haskell or Futhark, anyone familiar with Java/Javascript/TypeScript should be able to pick it up in a day or so.
Flutter's performance issues, on the other hand, is a separate story.
Flutter's performance issues, on the other hand, is a separate story.
Knowing nothing about Dart, I'd guess learning the language itself is not much of a task, but learning the libraries, build tools, and the whole ecosystem would take a while.
> Flutter's performance issues, on the other hand, is a separate story.
Can you expand on that? I know react native has performance issues but does Flutter have it too? Why?
Can you expand on that? I know react native has performance issues but does Flutter have it too? Why?
React native has less performance issues, since it uses native toolkit.
Flutter draws whole ui by itself: welcome to blinking cursor that consumes 5-15% CPU in idle.
Flutter draws whole ui by itself: welcome to blinking cursor that consumes 5-15% CPU in idle.
I don't think that's accurate. Seems like native apps have the best performance but Flutter comes a close second. React native on the other is much slower:
https://medium.com/swlh/flutter-vs-native-vs-react-native-ex...
https://medium.com/swlh/flutter-vs-native-vs-react-native-ex...
> welcome to blinking cursor that consumes 5-15% CPU in idle.
Citation? Flutter draws its own UI but game engines do that too.
All code in flutter compiles down to native code.
> React native has less performance issues, since it uses native toolkit.
In theory.
Citation? Flutter draws its own UI but game engines do that too.
All code in flutter compiles down to native code.
> React native has less performance issues, since it uses native toolkit.
In theory.
>Citation?
https://github.com/flutter/flutter/issues/59327
This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.
https://github.com/flutter/flutter/issues/59327
This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.
I think this might be a bit of an outlier honestly.
Reading the bug report my takeaways were the following:
1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.
2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.
3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)
They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.
I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.
Reading the bug report my takeaways were the following:
1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.
2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.
3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)
They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.
I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.
I don't know if there is a larger issue because this show stopping "outlier" has stopped me from exploring Flutter any further. I'll give it another try now that a new major version has been released.
The question in my mind is whether Flutter is consistently and significantly more resource efficient than web technologies for my particular use cases.
The question in my mind is whether Flutter is consistently and significantly more resource efficient than web technologies for my particular use cases.
Hey there. I'm an engineer working on Flutter Desktop. We're definitely aware of the macOS cursor behaviour issue and are looking at ways we can fix it. We haven't landed anything (that I'm aware of) that should improve this for 3.0, but if it helps, it's something that's actively on our radar and we've discussed potential fixes for. One potential solution is to implement a custom shader [1].
While I understand this may be a dealbreaker issue for your use-case, we've been pretty busy getting a few higher-priority (overall) issues fixed (universal binary support, CJK text input, key event APIs, etc.) prior to 3.0, but we'll get to this.
[1] https://github.com/flutter/flutter/issues/93416
While I understand this may be a dealbreaker issue for your use-case, we've been pretty busy getting a few higher-priority (overall) issues fixed (universal binary support, CJK text input, key event APIs, etc.) prior to 3.0, but we'll get to this.
[1] https://github.com/flutter/flutter/issues/93416
Flutter and Dart seemed to have been internal tools built by engineers looking for an interesting project to spend their time on while at Google.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
Java was already open-source at the time so the court fight’s outcome was meaningless from the view of what language to choose.
And Android would have been much better off if they didn’t fork the whole ecosystem and just used OpenJDK, perhaps with an added low-memory GC.
And Android would have been much better off if they didn’t fork the whole ecosystem and just used OpenJDK, perhaps with an added low-memory GC.
To be fair: Dart is relatively straight forward and simple to learn.
You should have decently qualified developers be productive within a week.
But forcing a new language on people usually doesn't go well.
You should have decently qualified developers be productive within a week.
But forcing a new language on people usually doesn't go well.
Sure, I'm not trashing the language, because I know nothing about it.
Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
Speaking from personal experience I found the process of using dart to be VERY painless. I'm mostly a web developer, but have taken some Java courses in college and have dabbled in a bit of C# outside of my normal PHP/JS work.
We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.
A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter app was really good.
It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.
YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.
We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.
A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter app was really good.
It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.
YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.
postalrat(1)
I wrote extensive amount of Dart without even reading documentation and any prior Dart experience. Knowing dart is never an issue if you know basic Java/Php/JavaScript.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't enjoy using it.
All anecdotal:
I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..."
The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available.
I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time.
Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart.
---
EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.
All anecdotal:
I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..."
The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available.
I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time.
Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart.
---
EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.
As an early Flutter adopter, the ecosystem was a big problem, and while it seems to have progressed, it's still pretty anemic compared to other language's ecosystems.
Here’s one from Google https://pub.dev/packages/functions_framework
> Google Cloud Functions does not currently provide an officially supported Dart language runtime, but we're working to make running on Google Cloud Run as seamless and symmetric an experience as possible for your Dart Functions Framework projects.
It's not natively supported - runs on Google Cloud Run instead.
It's not natively supported - runs on Google Cloud Run instead.
I’m not sure what you think cloud functions runs on under the hood? But it’s cloud run.
You said there were no good backend solutions for serverless functions and I’m telling you that is incorrect.
I’ve done a bunch myself, it was actually really pleasant.
You said there were no good backend solutions for serverless functions and I’m telling you that is incorrect.
I’ve done a bunch myself, it was actually really pleasant.
IIRC you can transpile Dart to JavaScript, so technically you can deploy it as serverless functions.
I may be missing something, but why would you want to build a serverless function in Dart? you want a common backend/frontend language?
I don't.
It is one of my arguments against devs trying to bring Dart into solutions. Historically, I have had colleagues push to use Dart for backend/cloud/automation work which I personally disagree with.
It is one of my arguments against devs trying to bring Dart into solutions. Historically, I have had colleagues push to use Dart for backend/cloud/automation work which I personally disagree with.
This is the entire reason for Node's existence no? Nobody who was in the backend space prior to it's arrival was in anyway excited about JS running in their servers. Node however allowed people with only front end experience to make that transition and start writing backend apps / logic / functions using the same language and now it's an insanely popular project.
Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams.
Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else.
However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption.
It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions.
Where I ended up landing was basically:
===Front End===
Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures.
===Backend===
Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits:
- Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf.
- Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe.
- Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to.
It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider.
- Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway) also get's me a free JSON / REST <-> gRPC gateway for web along with a free gRPC-web <-> gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport) makes native gRPC in the browser a viable option.
- Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default.
- Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works.
- The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code.
- Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc..
- The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild).
- The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about.
- Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment.
===Wrap Up===
That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair.
Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase.
But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that.
Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.
Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams.
Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else.
However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption.
It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions.
Where I ended up landing was basically:
===Front End===
Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures.
===Backend===
Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits:
- Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf.
- Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe.
- Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to.
It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider.
- Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway) also get's me a free JSON / REST <-> gRPC gateway for web along with a free gRPC-web <-> gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport) makes native gRPC in the browser a viable option.
- Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default.
- Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works.
- The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code.
- Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc..
- The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild).
- The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about.
- Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment.
===Wrap Up===
That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair.
Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase.
But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that.
Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.
Thank you for taking the time.
I keep hearing this, but none of the cross platform apps I run use Flutter. It's all Electron and Qt.
I don't think I've ever seen Flutter in the wild.
I don't think I've ever seen Flutter in the wild.
Or have you, and you just couldn't tell?
(I personally don't know if it's this good, but it's plausible)
(I personally don't know if it's this good, but it's plausible)
Not OP - but almost all of the Flutter work I've ran into is mobile-centric.
If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.
If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.
Given that "Today, we are excited to announce that Flutter is now stable for macOS and Linux, in addition to Windows!" thats not surprising
Of course, and to be clear I'm excited there are more cross-platform options even though I've had a reluctant history with Dart.
I read "I don't think I've ever seen Flutter in the wild" to include mobile, but maybe I misinterpreted
> ever seen Flutter in the wild.
So what is this made in then? [0] Hint it is not Electron.
[0] https://rows.com/download
So what is this made in then? [0] Hint it is not Electron.
[0] https://rows.com/download
Xamarin?
The referenced "Rows" application seems to be the showcase app "Rows" listed at
https://flutter.dev/showcase
https://flutter.dev/showcase
Exactly.
I have a few apps out there and you can’t tell them apart from native. They are insanely snappy. Flutter is the bomb.
I still maintain that Flutter Web is not production ready. It could have a nice niche, like games. But for real apps, it's just not as good as web. They are still re-implementing things that have existed in the web for ages, and are not going to be able to keep up. It's basically good for an applet style usage IMO. I'll keep trying it out, I think Flutter is pretty great for mobile, even desktop, but every time I use a web app example I find issues and just shake my head at what they did.
FWIW I kind of agree and I’m a big fan of both Flutter and the web in general.
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
Yah, this is a pretty solid list of things that, if they all hit and work as we hope they do, it could enable building things with tech like Flutter and having it work well. I think that's why I generally say FlutterWeb isn't production ready and not that it'll never be. I don't care for the path they took originally, it feels like a bandaid and has a lot of issues. They may get there eventually, and I'll be happy to adjust my position when/if they do.
I’m betting on Flutter web across a 2-3 year timeframe but none of the things I’ve listed there are conceptual ideas that are only going to land in the distant future.
WebGPU and WasmGC are both already implemented in most browsers and are currently just behind a flag as far as I know.
It doesn’t feel like magical thinking to me at all, it’s a pretty clear path forward IMO.
WebGPU and WasmGC are both already implemented in most browsers and are currently just behind a flag as far as I know.
It doesn’t feel like magical thinking to me at all, it’s a pretty clear path forward IMO.
Oh, I do mostly agree with you that it isn't magical thinking. I do think there were some choices made that might make it a bit more difficult to switch, but the Flutter team has been willing to make big shifts in the past.
Personally, I'm not willing to be on Flutter Web right now, and as you can see, I still actively dissuade it's use as I don't think it's good for the web as it is. But that doesn't mean that in a few years I'll think differently.
Personally, I'm not willing to be on Flutter Web right now, and as you can see, I still actively dissuade it's use as I don't think it's good for the web as it is. But that doesn't mean that in a few years I'll think differently.
Isn’t Dart a very JS-like language? I really don’t believe that compiling to JS would cause any bottlenecks at all, like compiling Java to JS is also possible with Google’s own Closure compiler which produces crazy fast JS output.
Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all.
Though surely the render codepath could use wasm, but that could be written natively as well without a need for GC.
As for WebGPU, I don’t think a web app would be okay with the latency of compiling shaders. Not sure whether it will be needed, or if it can be cached but it is not a trivial win either.
Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all.
Though surely the render codepath could use wasm, but that could be written natively as well without a need for GC.
As for WebGPU, I don’t think a web app would be okay with the latency of compiling shaders. Not sure whether it will be needed, or if it can be cached but it is not a trivial win either.
For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
Thanks for the informative answer!
> Flutter is by definition a canvas optimised framework
Not really, flutter has not the resources to develop their own 2D renderer so they use the chromium renderer for drawing. (Skia). It is canvas-like, everything is canvas-like at low level. But flutter like browsers implement retained mode rendering which is necessary for being jank free and have low energy consumption. Flutter on web canvas cannot properly do retained mode rendering.
spoiler, flutter non-web is generally slower than Ionic
spoiler, flutter non-web is generally slower than Ionic
CanvasKit still renders to canvas (maybe that's what you meant by "canvas-like", but it is still directly drawing to an HTML canvas), it just enables Flutter to utilize a more advanced feature set than the DOM canvas API. It also comes with a 2MB or so download (which is why by default it's off on mobile last I checked).
you did not understand my point, canvaskit is skia but slower, over wasm. It output to an HTML canvas and HTML canvas are immediate mode, they do not have retained mode rendering (display lists, occlusion, caching, etc).
Besides I don't think canvaskit is faster than regular HTML canvas. Even if canvaskit might avoid some compute that would normally be done at the HTML canvas level, canvaskit could implement retained mode rendering but 1) it does not 2) it would not really be appropriate because of the unstructured API (unlike DOM), 3) the final HTML canvas would still behave immediately.
As I said, it's important to realize that you are rendering skia (html canvas) on skia (canvaskit wasm) the amount of overhead and rendering duplication is in theory crazy.
SEO is important for web apps, how do canvas based applications deal with that.
SEO is important for websites which for the record you 100% should not use Flutter for.
Flutter is a great fit for applications which (and I say this as someone who did SEO for fortune 500s for many years) aren’t really all that relevant for SEO purposes and are difficult to index at best.
But the short answer to your question is the accessibility object model API is what gets used to surface relevant information that could be used by search engines along with all the other things that have nothing to do with the stuff that sits inside your body tags. Like it wouldn’t actually be that different IRL.
Flutter is a great fit for applications which (and I say this as someone who did SEO for fortune 500s for many years) aren’t really all that relevant for SEO purposes and are difficult to index at best.
But the short answer to your question is the accessibility object model API is what gets used to surface relevant information that could be used by search engines along with all the other things that have nothing to do with the stuff that sits inside your body tags. Like it wouldn’t actually be that different IRL.
Important for web apps or websites? There's a difference, a product's landing page will need SEO, definitely, but the app itself, ie app.example.com, likely does not need SEO. For example, an easy example is Figma. The landing page is built with HTML, CSS and JS, but the actual app itself is actually built with WASM [0], very similar to the canvas based implementation of Flutter apps.
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
I'm not sure there's a good distinction between web apps or websites today.
Would you consider Instagram or Twitter a website or a web app?
If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.
Would you consider Instagram or Twitter a website or a web app?
If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.
True, if the app needs SEO, then yes it should be built with HTML, CSS and JS, and not Flutter which uses a canvas element. However, there are many apps where SEO is unneeded, such as Figma above (no one will search for your company's design files on Google) or other such corporate apps, and that's where Flutter comes in handy.
The way it atleast used to be framed is that web is a fallback target. Meaning if the target device isn't running Linux, Windows, macOS, iOS or Android (unlikely), then hey, you can atleast build a passable version that will run in a browser.
I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
I’ve encountered a Flutter web app exactly once, https://app.travellerdeclaration.govt.nz/. It was very painful. (Part of the pain was related to them using a selectable-button style for radio buttons, which isn’t entirely Flutter’s fault, though I bet it contributed to that misguided decision; but when there’s no scrollbar and the Yes/No button you clicked is at the very bottom of the visible page—well, that was the position.) When I filled it out last year, they had an alternative, vastly better accessible version that I think didn’t even require JavaScript, though good luck finding it, since it was accessed by an invisible button that Flutter event handling made unfocusable. Now that button sets a flag in sessionStorage and reloads, and on startup checks for the flag and sets flutterWebRenderer = "html", so that at least the content is in the accessibility tree, even if they still badly reimplement half the stuff the browser provides manually (links, focus, scrolling, they even damage bits of IME).
That was painful indeed! Why you would use Flutter for something that seems to be web-only, and on a govt website that presumably values accessibility, is beyond me.
No, it is 100% being framed as "You can build your app once and deploy it everywhere" with everywhere including web. It's sorta maddening, IMO. There are certain types of apps I could see using Flutter for (basically, ones that would lean heavily on canvas anyways, games, drawing, etc.)
It's hard to quantify exactly what "everywhere" means, but for the vast majority of end-user devices, you'll have a more efficient Flutter build target than web.
You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
Just to be clear, I used the word everywhere. I believe they are quite a bit more explicit in framing it for all platforms, including web specifically. It's possible we'll see it get there, but I think there is a lot of things to do (and undo) to do that.
For what it’s worth Dart is hands down the nicest OOP language I’ve ever used in my opinion.
It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.
It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.
I think the decision of which cross platform technology to use mostly depends on a team's preferred tech stack.
C++ -> QT
C#/.NET -> MAUI/Blazor
JS/Web -> React.Native/Electron
Dart -> Flutter
This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
C++ -> QT
C#/.NET -> MAUI/Blazor
JS/Web -> React.Native/Electron
Dart -> Flutter
This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
I've used PySide6 recently and I must say it's great, so you can also add Python to Qt's side.
Kotlin -> Jetpack Compose
> Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)
> Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)
[deleted]
Qt has some pretty good bindings for other languages other than C++.
note that many languages credibly interop with JS/TS nowadays
Rust -> ='[
> nicest OOP
That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
They are building pattern matching as we speak for what it’s worth. One of the main people designing it is in this thread talking about it.
Thought this link might actually be more helpful by the way if you're interested but Dart team does all of their language design in the open on Github which is pretty cool and also gives you a lot of context about how things end up the way they do.
I also mentioned elsewhere in the thread how impressed I was just watching that repo in general for a year. They clearly give a shit on a such a deep level about building a solid long term language in a way that I was totally unfamiliar with say coming from a Ruby background previously.
Here is the section on pattern matching specifically https://github.com/dart-lang/language/tree/master/working/05... and this is the design spec itself https://github.com/dart-lang/language/blob/master/working/05...
I also mentioned elsewhere in the thread how impressed I was just watching that repo in general for a year. They clearly give a shit on a such a deep level about building a solid long term language in a way that I was totally unfamiliar with say coming from a Ruby background previously.
Here is the section on pattern matching specifically https://github.com/dart-lang/language/tree/master/working/05... and this is the design spec itself https://github.com/dart-lang/language/blob/master/working/05...
People being pleased with Dart is only because they have not tasted better, everything is relative. Kotlin is miles ahead.
Yes, of course, everyone who disagrees with me is just an idiot who doesn’t know better. Excellent discourse.
That's right, my discourse has no argumentative value. I do not advance any substance allowing you to agree or disagree. It's just a difference at the premise level, I have experienced dart and I have experienced Kotlin. Learn boths properly (reading the kotlin guide is sufficent and can be done in an afternoon) and then you will be able to judge if I was wrong or not. From experience, the difference is huge and affect every aspects/features of the language, without even talking about the JVM ecosystem interop.
You seem to have a lot of very strongly held opinions in this thread that aren’t backed up by any evidence other than your personal opinion.
It’s clear that Flutter wasn’t for you for whatever reason and you seem to love Iconic which is great but obsessively hanging out on this thread and just trying to shit all over it at every opportunity you get without citing any evidence is weird.
Just go an enjoy Iconic. I don’t know why you keep trying to pick arguments with everyone here.
It’s clear that Flutter wasn’t for you for whatever reason and you seem to love Iconic which is great but obsessively hanging out on this thread and just trying to shit all over it at every opportunity you get without citing any evidence is weird.
Just go an enjoy Iconic. I don’t know why you keep trying to pick arguments with everyone here.
Someone else told him he should disclose that he works for Ionic and he’s claiming that he doesn’t work there. I don’t buy it, because the CEO of Ionic himself responded to me in this thread with some equally dismissive comments. Really weird behavior and it makes the Ionic team look super thin-skinned.
No, the ionic CEO yesimahunan often comment on HN and give generally neutral statements.
I am sick of people ignorance in GUI rendering engines and the religious myths they build over native, so I actively comment too because online GUI conversations are still on a middle age like era. If I wzs tied to Ionic I would try to please people, which I don't. In fact Ionic communication has often self victimized itself by corroborating the native rendering myth in lany of their blogs. The internet and HN indeed is a small place and seeing the Ionic CEO and one of the only person with expertise in 2D GUI renderers (me) on thr flutter 3.0 announcement is actually, not unlikely. But it surprises because on average on the internet, people don't care to push depth/accuracy into discussions.
BTW I am capable of pointing flaws in Ionic, the documentation on the web is often not up to date, and inn general I would much prefer a Kotlin based GUI framework (such as jetpack compose) over a JS framework (ionic). I am in fact the only person on HN to have an actual argument to defend a true Ionic competitor, based either on fastuidraw, piet-gpu or gecko but there's no point in discussing this given no one could contribute to the discussion.
I am sick of people ignorance in GUI rendering engines and the religious myths they build over native, so I actively comment too because online GUI conversations are still on a middle age like era. If I wzs tied to Ionic I would try to please people, which I don't. In fact Ionic communication has often self victimized itself by corroborating the native rendering myth in lany of their blogs. The internet and HN indeed is a small place and seeing the Ionic CEO and one of the only person with expertise in 2D GUI renderers (me) on thr flutter 3.0 announcement is actually, not unlikely. But it surprises because on average on the internet, people don't care to push depth/accuracy into discussions.
BTW I am capable of pointing flaws in Ionic, the documentation on the web is often not up to date, and inn general I would much prefer a Kotlin based GUI framework (such as jetpack compose) over a JS framework (ionic). I am in fact the only person on HN to have an actual argument to defend a true Ionic competitor, based either on fastuidraw, piet-gpu or gecko but there's no point in discussing this given no one could contribute to the discussion.
fwiw I totally agree with your other comment on the insanity of CanvasKit. I'm just digging into low-level rendering myself, and immediately thought...wait, so you're writing in Skia, only to be compiled into WASM, feeding into a 2D canvas context, which is rendered by...Skia? tf?
Sometimes people must be protected from themselves and from the delusions of misinformation.
See a recent example of people having their lifes ruined because they have been fooled by the promise of a crypto stablecoin here https://www.reddit.com/r/TerraLuna/
I mean yes flutter or newShinyFrameworkX does not cause as much harm and it is much more subtle. But the platform does matter. We are building user experiences, things that people will experience, a LOT.
Any non-web solution is much inferior in terms of feature completeness/expressivity, and conteary to popular belief, is inferior in performance and energy efficiency.
So yes I might have commented too much in this thread but that is a political act in essence, trying to advocate for the serious trustable solution that receive the most human resources.
It's not remotely a realistic option. CJK is all second class citizen. I just tried their latest demos. Tried to enter 日本. It utterly failed. First it's still trying to draw on it's own so you get to see some placeholder □ while typing. Then, it effup and typing n-i-h-o-n kept producing Nいほん on this example
https://gallery.flutter.dev/#/demo/cupertino-text-field
As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI
https://gallery.flutter.dev/#/demo/cupertino-text-field
As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI
Thanks for reporting this. IME-based input is super important to me -- we only speak Japanese at home. I've filed a bug [1].
I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed.
[1] https://github.com/flutter/flutter/issues/103645
[2] https://www.youtube.com/watch/0Bt-c9-h92c
I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed.
[1] https://github.com/flutter/flutter/issues/103645
[2] https://www.youtube.com/watch/0Bt-c9-h92c
Fixing that one bug won't fix the plethora of issues
* emoji is not the system emoji.
* neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered)
* reconvert and other IME options don't work
just to name a few. Just please stop with the canvas rendering!
* emoji is not the system emoji.
* neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered)
* reconvert and other IME options don't work
just to name a few. Just please stop with the canvas rendering!
[deleted]
they got clojuredart now, which is still kind of a fly-by-night thing but those Roam Research peeps are apparently using it in production
https://github.com/Tensegritics/ClojureDart
(and in turn, clojure itself is a highly opinionated thing which isn't gonna turn into a blub that everyone uses...)
https://github.com/Tensegritics/ClojureDart
(and in turn, clojure itself is a highly opinionated thing which isn't gonna turn into a blub that everyone uses...)
> Apart from Qt , but the licensing issue is a hindrance.
Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened.
Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said.
In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends.
With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened.
Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said.
In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends.
With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
We just built a desktop app with QML in a CMake-based Qt project, and I've been pleasantly surprised by the experience.
Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
So interesting, even after years of doing QML, layouting with widgets makes for me much simpler to get what I want
QtQuick Controls 2's QML widgets, along with whatever KDE's MauiKit QML widgets are called now, might suit your needs.
I don't know, the new QQC tree view does not look as powerful as QTreeView which is a real workhorse
> Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit.
That matches my experience. Getting Qt Widgets to resize in an even remotely sane way proved to be just about impossible.
That matches my experience. Getting Qt Widgets to resize in an even remotely sane way proved to be just about impossible.
I was thinking MAUI(rebranded Xamarin) might be somewhat useful with .NET6 coming out. I've been playing with it the last week or so, it's quite nice.
Pretty sure it excludes Linux as a GUI target.
It has a Skia target (in Microsoft.Maui.Graphics) which is theoretically very similar to how Flutter does UI.
Did they give up on GTK? I remember Suse Linux Enterprise in particular shipped with a bunch of nice .NET/GTK apps that seemed to work well.
They did. Gtk# hasn't seen updates in ages.
Nice, thanks for the correction.
There's ClojureDart, which means you can now do Dart and Flutter development in Clojure: https://github.com/Tensegritics/ClojureDart
Anyone has used this? Opinions?
It's very new, like, a month or so old, but I'm seeing quite a few people experimenting with it already in the Clojure community. Roam Research (https://roamresearch.com/) has their mobile apps built with it.
I've had to bounce around from Mac, Windows and Linux for work, the main programs I use everyday are all Electron based (Postman, VS Code, Spotify etc), they all behave basically the same just everything is slower in Windows on my laptop. Egui (immediate mode GUI) and Tauri (like Electron but Rust backend) have worked well cross platform just messing around with them, but I haven't used any big apps yet to know for sure.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?
Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?
Flutter and Dart have co-evolved to the extent that separating them would be difficult.
One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to.
Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript.
Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance.
Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to.
Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript.
Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance.
Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
> Go doesn't have an easy way to bulk-copy fields from one struct to another
FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct.
https://go.dev/doc/effective_go#embedding
FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct.
https://go.dev/doc/effective_go#embedding
> realistic option for true cross platform UIs that run everywhere
I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too.
People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho.
Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...
I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too.
People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho.
Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...
I don't know the history, but wouldn't Kotlin be a saner approach? Better language and at least native to android.
nowadays you can do web programming in KotlinTS
I quite like Dart. I can't remember what they're called, but I remember it has something that lets you declare a stream (actually, maybe that's what it's called) that I thought was pretty ergonomic.
> Flutter is the only realistic option for true cross platform UIs that run everywhere.
Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user?
That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.
Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user?
That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.
We really want cross platform on Android and iOS. Windows and MacOS are nice to have, why not?
Who is “we”? As a user I want highly polished, efficient apps. That pretty much rules out anything built with a cross platform toolkit. (Games are a major exception.)
As a developer, I personally want to make those kinds of programs too. I periodically check into the state of the cross platform toolkits and frankly they really aren’t any better than they were a decade ago.
Separating out a UI layer that is unique in each platform helps and writing with native toolkits helps, but there are still fundamental differences that you can’t really abstract away.
I think the biggest market for these toolkits is in enterprise software. There, lowering development costs seems to be more important than anything else.
As a developer, I personally want to make those kinds of programs too. I periodically check into the state of the cross platform toolkits and frankly they really aren’t any better than they were a decade ago.
Separating out a UI layer that is unique in each platform helps and writing with native toolkits helps, but there are still fundamental differences that you can’t really abstract away.
I think the biggest market for these toolkits is in enterprise software. There, lowering development costs seems to be more important than anything else.
I think this assumption that cross platform UI solutions can’t be extremely fast is a very strange one.
There have been some bad efforts at this in the past which is maybe how you arrived at the conclusion but the concept of Flutter is pretty straightforward and not dissimilar to games in some sense where you just need to push pixels to a screen.
They even have a some game engineers who used to work at EA on the team. One even wrote a popular book on it https://gameprogrammingpatterns.com/
Like in short, Flutter is going to be fine. It compiles to native code that just needs to push pixels to a screen, it has a bunch of smart people on it and some extremely heavy incentives to get this right.
There have been some bad efforts at this in the past which is maybe how you arrived at the conclusion but the concept of Flutter is pretty straightforward and not dissimilar to games in some sense where you just need to push pixels to a screen.
They even have a some game engineers who used to work at EA on the team. One even wrote a popular book on it https://gameprogrammingpatterns.com/
Like in short, Flutter is going to be fine. It compiles to native code that just needs to push pixels to a screen, it has a bunch of smart people on it and some extremely heavy incentives to get this right.
They can be fast, but a well written browser based solution will usually be slower, use more memory and CPU than a well written native app.
Of the toolkits I’ve looked into (which admittedly are mostly on the desktop), Qt is probably the best on that front.
Of the toolkits I’ve looked into (which admittedly are mostly on the desktop), Qt is probably the best on that front.
As a user, I want native apps with some added value compared to web apps. I don't actually care about "polished", 60fps and things like that. So we are in a different camps.
I disagree, Flutter is probably the worst choice. React Native is the all around best choice for targeting all platforms natively, otherwise use pure web tech (Ionic + Electron)
The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time.
Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling.
React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
Then there's the question as to why would you choose a Google only language and framework with their track record.
With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.
The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time.
Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling.
React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
Then there's the question as to why would you choose a Google only language and framework with their track record.
With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.
Every experience I had with React Native was truly horrible.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
I wouldn't touch it again.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
I wouldn't touch it again.
That's the story with Javascript in general, the tooling is just terrible.
This is one of the underappreciated part of flutter, 4 months of upgrade take me 30min of work and the hot reload just works, good luck with that in the JS world.
This is one of the underappreciated part of flutter, 4 months of upgrade take me 30min of work and the hot reload just works, good luck with that in the JS world.
I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"?
Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
> I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"?
Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion.
Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade issues only after a month...
> Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
You need much less native tooling in Flutter since almost everything is canvas based. Broken stuff on the native part is very rare, I can't really remember anything like this from the past 3 years. I had to upgrade the graddle version once but that's about it.
I have ~30k lines of dart excluding tests and about 15 lines of Kotlin (and zero in ios), that's the kind of ratio we're talking about.
Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion.
Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade issues only after a month...
> Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
You need much less native tooling in Flutter since almost everything is canvas based. Broken stuff on the native part is very rare, I can't really remember anything like this from the past 3 years. I had to upgrade the graddle version once but that's about it.
I have ~30k lines of dart excluding tests and about 15 lines of Kotlin (and zero in ios), that's the kind of ratio we're talking about.
> Packages are usually poorly tested
Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
> and the fact that it's dynamic language does not help
Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.
> upgrades are often and painful
You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
> the tooling is not very stable in my opinion.
Seems stable to me since the last couple years.
Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
> and the fact that it's dynamic language does not help
Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.
> upgrades are often and painful
You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
> the tooling is not very stable in my opinion.
Seems stable to me since the last couple years.
Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
> Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.
The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.
The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
> In general, it's not really part of the js culture
As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
React you can snapshot test the component tree, as well as diff images on each platform.
> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
That's plain false, they for sure do.
> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
React Native performs well on older devices as well.
As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
React you can snapshot test the component tree, as well as diff images on each platform.
> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
That's plain false, they for sure do.
> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
React Native performs well on older devices as well.
> As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
Not every ecosystem is created equal, they are better testing cultures than dart (such as ruby for example) but they are also worse ones and javascript is definitely worse at that. Packages you install will be on average less tested and less care will be put into the dev experience than in some other languages.
They are exceptions of course such as RN & React but they are far outside the norm.
> Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
As with any other JS project, RN and React are not the main issue but everything around it is and you certainly need extra packages.
> That's plain false, they for sure do.
Have a look at those apps and tell me if they look Material (they don't).
Not every ecosystem is created equal, they are better testing cultures than dart (such as ruby for example) but they are also worse ones and javascript is definitely worse at that. Packages you install will be on average less tested and less care will be put into the dev experience than in some other languages.
They are exceptions of course such as RN & React but they are far outside the norm.
> Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
As with any other JS project, RN and React are not the main issue but everything around it is and you certainly need extra packages.
> That's plain false, they for sure do.
Have a look at those apps and tell me if they look Material (they don't).
Highly recommend trying expo.dev sometime they have come a long way in providing support for native modules and take care of all that underlying "mess" for you.
I absolutely agree with this. At this point I don't really think there's much reason to _not_ use Expo. I found setting up RN without Expo absolutely awful, and switching to Expo was the only reason I didn't start rebuilding my app in Kotlin+Swift.
There's Expo if you don't want to setup your own stack.
You certainly don't need it though, I have no issue with my React Native stack.
Flutter has its share of similar tooling issues, most of the time its native things like CocoaPods that affect both projects.
RN has a huge amount of plugins, a lot that are very good quality. It's up to the dev to pick quality dependencies.
You certainly don't need it though, I have no issue with my React Native stack.
Flutter has its share of similar tooling issues, most of the time its native things like CocoaPods that affect both projects.
RN has a huge amount of plugins, a lot that are very good quality. It's up to the dev to pick quality dependencies.
> React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst.
All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
You can wrap the React Native Web target in Tauri or Electron for Linux.
There's also https://github.com/valence-native/valence-native that can use either wxWidgets or Qt.
All in all it's better than the current Flutter web / desktop implementation.
There's also https://github.com/valence-native/valence-native that can use either wxWidgets or Qt.
All in all it's better than the current Flutter web / desktop implementation.
Politely, I would point out that the makers of Ubuntu have said that as far as they are concerned Flutter is the future of desktop app development on Linux and all their projects moving forward will be using it by default because they believe in it so much.
They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.
It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.
They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.
It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.
> There's also https://github.com/valence-native/valence-native that uses Qt.
There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.
> You can wrap the React Native Web target in Tauri or Electron for Linux.
That's one of the only realistic solution for now in my opinion.
There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.
> You can wrap the React Native Web target in Tauri or Electron for Linux.
That's one of the only realistic solution for now in my opinion.
> There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter.
Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
> That's one of the only realistic solution for now in my opinion.
Yup, and you get it for free with if you build your app with RN and React Native Web.
Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
> That's one of the only realistic solution for now in my opinion.
Yup, and you get it for free with if you build your app with RN and React Native Web.
> Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
Even the simplest bridge needs upgrades, unless you want to be stuck with react 16.
> Yup, and you get it for free with if you build your app with RN and React Native Web.
That's better than nothing I'd say yeah. That's kind of the issue with react native, you need platform-specific rendering code and since companies don't really care that much about linux desktop it's not really there.
Even the simplest bridge needs upgrades, unless you want to be stuck with react 16.
> Yup, and you get it for free with if you build your app with RN and React Native Web.
That's better than nothing I'd say yeah. That's kind of the issue with react native, you need platform-specific rendering code and since companies don't really care that much about linux desktop it's not really there.
Don't forget native targets for TVs (well android TV at least)
> Apart from Qt, but the licensing issue is a hindrance
Qt is LGPLv3, which is really a problem only if you plan to develop embedded software.
Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)
Qt is LGPLv3, which is really a problem only if you plan to develop embedded software.
Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)
How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
If you to sell closed-source software be a good boy/girl and give part of the money pile to Qt developers, so that they keep working on Qt.
And I do. I'm just saying that is not operating under GPL.
I have never seen anyone statically linking Qt anywhere, even with a commercial license. The main issue is iOS, where it's basically impossible to ship anything (L)GPLv3 on the app store, but that's due to Apple's lock-in policies.
Also, JNI requires you to use DLLs/shared objects, so you definitely can use them on Android.
Also, JNI requires you to use DLLs/shared objects, so you definitely can use them on Android.
> I have never seen anyone statically linking Qt anywhere, even with a commercial license.
from a quick grep on my hard drive, Telegram and QBittorrent statically link against Qt on Windows ; my own software also does, on all platforms. I assume there are others.
from a quick grep on my hard drive, Telegram and QBittorrent statically link against Qt on Windows ; my own software also does, on all platforms. I assume there are others.
LGPL is not about dynamic linking, and there are plenty of LGPL (and even GPL) apps in the Apple, Android, Mac and Windows app stores. Like, Chromium itself is mostly LGPL and it's never an issue for electron apps, why would it be for Qt ones
LGPL IS about dynamic linking if you don't want to release your source. That's the workaround.
You can use LGPL with closed source so long as you provide object files to relink against.
> Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere.
What are your thoughts on flutter vs react native?
(assuming you're only targeting phones)
What are your thoughts on flutter vs react native?
(assuming you're only targeting phones)
One anecdote that I find compelling here is looking at how each of the parent companies think of them.
The majority of Google’s revenue is directly tied to their Ads platform.
Their mobile app is written in Flutter and the web interface is written in Dart (not flutter as flutter web support is like around a year old).
Facebook uses React on the web and abandoned react native on mobile.
Both are responsible for billions of dollars but only one passed the test.
The majority of Google’s revenue is directly tied to their Ads platform.
Their mobile app is written in Flutter and the web interface is written in Dart (not flutter as flutter web support is like around a year old).
Facebook uses React on the web and abandoned react native on mobile.
Both are responsible for billions of dollars but only one passed the test.
> Facebook uses React on the web and abandoned react native on mobile.
That's not true, FB very much still uses RN on mobile.
That's not true, FB very much still uses RN on mobile.
The Facebook app is not written in React Native. They tried it and famously abandoned it no?
The Marketplace tab in the FB app is written in React Native.
The Ads Manager app is written in React Native.
The Instagram app is written in React Native.
The entire FB app is not written in React Native yet, but overtime I'd expect more things to be.
The statement that FB "abandoned react native on mobile" is demonstrably false.
The Ads Manager app is written in React Native.
The Instagram app is written in React Native.
The entire FB app is not written in React Native yet, but overtime I'd expect more things to be.
The statement that FB "abandoned react native on mobile" is demonstrably false.
I don't think the entire Instagram app is written in React Native. Only parts of it.
Someone currently on the Instagram team can correct me if I'm wrong.
Someone currently on the Instagram team can correct me if I'm wrong.
It seems unlikely that FB would give up on Litho, which is extremely performance focused, to use react native instead. Not for their bread & butter flagship news feed anyway https://fblitho.com/
First, both Litho and React Native build on Yoga so there's a fair amount of code sharing.
Second, they serve different purposes. Litho will be used for FB scale optimization of certain intensive views. React Native is used for fast developer productivity. I'd wager that RN will be used in most places and Litho is used in hot spots sparingly.
Second, they serve different purposes. Litho will be used for FB scale optimization of certain intensive views. React Native is used for fast developer productivity. I'd wager that RN will be used in most places and Litho is used in hot spots sparingly.
If I’m wrong then I’m happy to admit it. I don’t follow that ecosystem closely and was only going off a few old blog posts I remember and everyone making a big deal of it at the time.
If React Native is good enough for Discord, it's good enough for a lion's share of applications out there.
No, they abandoned the Facebook app written in html.
Not GP but my comparison is here:
https://news.ycombinator.com/item?id=31346887
https://news.ycombinator.com/item?id=31346887
I tried Flutter in 2020 for a side project but decided not to use it. It felt clunky and slow. I later ditched the side project also since I decided to not build any mobile Apps for now. Maybe I'll revisit Flutter if I ever consider building a mobile front end for any side-projects.
There's definitely competitors opening up and realizing the space is worth the investment. C# Maui for example, especially with Blazor, is extremely cross platform as well(including web), but it has full party support in C#.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart
Why did they tie Flutter to Dart anyway?
Why did they tie Flutter to Dart anyway?
Take a look at this video from the team that talks about this exact topic. After watching it initially it became very obvious to me why and I agree it was the right choice https://youtu.be/J5DQRPRBiFI
What about .NET with MAUI / Xamarin?
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript
Sounds like they should have used TypeScript?
Sounds like they should have used TypeScript?
TypeScript isn't a language that can compile to machine code. It must be converted and distributed as JavaScript bundle, which is slow compared to Dart.
> Dart isn't horrible
Dart is horrible and the sole reason i don't touch Flutter
Dart is horrible and the sole reason i don't touch Flutter
> is the only realistic option for true cross platform UIs that run everywhere
wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.
wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.
Ionic is pretty awful too, though I can't fault them. It's just that papering a web interface on top of a native app is gonna be a poor experience no matter what.
I don't think that's how Ionic developers would describe it today. Have you actually used it or Capacitor recently? The quality of apps being built on the platform has never been higher. (one random example: https://reflect.app)
For what it's worth I'm an Ionic developer and I find the grand-parent's description pretty accurate. I do like Capacitor though, but I think that's mostly because I've had to deal with Cordova before.
Please pin point the relevant DX issues so that it can get recognition and get fixed
I feel like I'm having a deja-vu. I remember having a similar discussion in the past and it turns out it happened exactly one year ago when Flutter 2 was released: https://news.ycombinator.com/context?id=26336657
Every framework has bugs and feature requests that are fighting for resources. And the ones affecting you _always_ seem more important than the ones that don't.
That being said, the fact that memory leaks in widely used components (e.g.: `<ion-img>` [1]) go mostly unnoticed both by Ionic developers and by the community [2] just doesn't give me confidence in Ionic being a framework used to build quality apps.
Every framework has bugs and feature requests that are fighting for resources. And the ones affecting you _always_ seem more important than the ones that don't.
That being said, the fact that memory leaks in widely used components (e.g.: `<ion-img>` [1]) go mostly unnoticed both by Ionic developers and by the community [2] just doesn't give me confidence in Ionic being a framework used to build quality apps.
[1] - https://github.com/ionic-team/ionic-framework/issues/19242#issuecomment-556182556
[2] - the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`, which seems even more serious and the developers have been made aware of itwelcome back,
about the issue you mentioned, one of the original author wrote a blog in how to address it and how the issue is related to angular.
https://github.com/ionic-team/ionic-framework/issues/25283
It does make a significant difference in profiling though
> the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`
It looks like you answered yourself, this issue does not seem to affect people. Either it is a rare intermittent or only happen in very specific configurations, either there is a leak but it is negligeable, or shortlived. OR maybe this leak cause suboptimal performance but it must not be "feelable" although you did a great find, this issue has been overlooked and its severity should be better investigated. I'd like to remind you that Ionic is not the point, Ionic is simply a packaging of good practices and optimized components (because yes ion-img implement important optimizations over a normal img tag). Some might have leaking issues but the point is that you can trivially use a standard img tag, or a regular react/angular image lazy loading library or even better https://chromestatus.com/feature/5637156160667648 The web BTW will probably be the first ecosystem to provide support for JPEG XL images, which are a significant evolution in performance. Compare the discussed underinvestigated suboptimality with e.g. this 50% CPU increase over a trivial GIF, and mostly ignored/delayed https://github.com/flutter/flutter/issues/88858 or even https://github.com/flutter/flutter/issues/94205
> Every framework has bugs and feature requests that are fighting for resources. relativism has its limits, chromium has thousands more human resources than flutter and react native devs combined
It looks like you answered yourself, this issue does not seem to affect people. Either it is a rare intermittent or only happen in very specific configurations, either there is a leak but it is negligeable, or shortlived. OR maybe this leak cause suboptimal performance but it must not be "feelable" although you did a great find, this issue has been overlooked and its severity should be better investigated. I'd like to remind you that Ionic is not the point, Ionic is simply a packaging of good practices and optimized components (because yes ion-img implement important optimizations over a normal img tag). Some might have leaking issues but the point is that you can trivially use a standard img tag, or a regular react/angular image lazy loading library or even better https://chromestatus.com/feature/5637156160667648 The web BTW will probably be the first ecosystem to provide support for JPEG XL images, which are a significant evolution in performance. Compare the discussed underinvestigated suboptimality with e.g. this 50% CPU increase over a trivial GIF, and mostly ignored/delayed https://github.com/flutter/flutter/issues/88858 or even https://github.com/flutter/flutter/issues/94205
> Every framework has bugs and feature requests that are fighting for resources. relativism has its limits, chromium has thousands more human resources than flutter and react native devs combined
I have been working with it recently, yes. Again, I'm not criticizing their tech, moreso the underlying idea - rendering a webview as if it's a native app.
Seeing the quality of apps coming from the community especially with the latest updates in Ionic 6, I can’t agree with your framing at all. The team is highly receptive to specific feedback if you have anything we should improve or GitHub links
sounds very unsubstantiated. please examplify, Ionic capacitor native support is excellent, in fact you can arbitrarilly call the android/IOS SDKs, with or without nativescript.
You do understand there is no native difference between Ionic and flutter right?
Not sure what kind of substantiation you're looking for, but I've been working with Ionic and Capacitor for over 6 months now, as part of an ongoing client project. Previously, I worked with Cordova way back in 2015/2016. So I'm familiar with the technology. My comment addressed the fact that I'm not criticizing the tech, I'm criticizing the overall concept - rendering an application inside of a web view as if it's a native app.
I fail to see the issue here
> rendering an application inside of a web view as if it's a native app.
That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported on the web 2) most apps should not be in material design if they want to have a personality.
You said the word awful, don't you have concrete pain points?
That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported on the web 2) most apps should not be in material design if they want to have a personality.
You said the word awful, don't you have concrete pain points?
Just a hint: if you work for Ionic it's customary on HN to disclose that fact.
Also: what makes a framework "native" for me is that it has it's own rendering stack. With webview solutions you are still facing cross platform inconsistencies between Safari/iOS, Android and Electron.
Also: what makes a framework "native" for me is that it has it's own rendering stack. With webview solutions you are still facing cross platform inconsistencies between Safari/iOS, Android and Electron.
I am not an Ionic employee, I have zero affiliation. I am a hobbyist in GUI rendering libraries technologies, which include Skia, blend2d, pathfinder, webrender, piet-gpu, etc
> what makes a framework "native" for me is that it has it's own rendering stack
lel, the point of react native is exactly that it doesn't have its own rendering stack, it defer rendering to external rendering stacks (android native lib, swift native lib) Flutter and the web are not native and are not different. They both have their own custom rendering stack, which allow them to improve it. flutter has not created its own 2d renderer btw, it uses the chromium 2D renderer named skia, in fact android native use the chromium 2D renderer since a few versions already. Simply because its the fastest to exist.
> With webview solutions you are still facing cross platform inconsistencies
crazy how reversed with reality your argument is. React native is by design inconsistent, it uses a separate library for each platform which result in an impedence mismatch of features, performance, and bugs. A webview has no inconsistencies between android and electron, it's the same chromium behind. Safari is slighly inconsistent (webkit) but order of magnitudes less than using a completely different library.
> what makes a framework "native" for me is that it has it's own rendering stack
lel, the point of react native is exactly that it doesn't have its own rendering stack, it defer rendering to external rendering stacks (android native lib, swift native lib) Flutter and the web are not native and are not different. They both have their own custom rendering stack, which allow them to improve it. flutter has not created its own 2d renderer btw, it uses the chromium 2D renderer named skia, in fact android native use the chromium 2D renderer since a few versions already. Simply because its the fastest to exist.
> With webview solutions you are still facing cross platform inconsistencies
crazy how reversed with reality your argument is. React native is by design inconsistent, it uses a separate library for each platform which result in an impedence mismatch of features, performance, and bugs. A webview has no inconsistencies between android and electron, it's the same chromium behind. Safari is slighly inconsistent (webkit) but order of magnitudes less than using a completely different library.
> only realistic option for true cross platform UIs that run everywhere
Depending on your needs, Livecode has you covered. https://livecode.com
Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
Depending on your needs, Livecode has you covered. https://livecode.com
Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
I was recently tasked to build a mobile app at my work, that would have maybe 5% of the feature-set of our gargantuan web product. However, this 5% was mission critical. Coming from React-TS, building with Flutter was a bit weird at first (where's my CSS???) but the productivity gains came quickly. The Pub ecosystem is fairly mature, in that all the third party packages are pretty high quality and address most common use cases. Unlike npm where there are 10+ solutions for the same problem, there will only be one - maybe 2 in Flutter land.
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
Having used Flutter web in production, I would overall advise against it. It can be brilliant for building forms with elaborate validation logic - and quickly so, but once the site gets heavier and you add more complexity to it, the more issues will pop up. There are still major issues they haven't sorted out yet like occasional odd behavior with input fields and autofocus on Safari etc.
I'm also used to functional programming. The only thing I can not stand about Dart is that types are coupled to classes. If you want to use stateless functions and typed data shapes, you're out of luck. Compare this to TypeScript that truly allows both paradigms and has a very expressive type system.
Doesn’t `typedef` let you specify arbitrary type aliases for pretty much anything in Dart? Or are you talking about something else? For my own curiosity, can you provide an example of Typescript vs Dart in this case?
Flutter 3 comes with an upgrade to Dart 2.17 [1], which has quite a few improvements as well... including state on enums.
While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Well, at least there's quite a few other small but useful improvements... and they showed how they really listen to the community by implementing the new syntax for passing on constructor parameters to a super-class... and by improving the docs of the 200 most popular packages with lots of examples, as requested by the people.
I like how they're listening to the community as well to implement meta-programming (like macros) [2] to solve the main pain point, currently, in Dart, which is how verbose it is to generate code for things like serialization and data types.
Once they get that, Dart will be a really good language to work on (it's already quite ok IMO, despite most people, usually those who don't actually use it much, hating on it).
[1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d
[2] https://github.com/dart-lang/language/issues/1482
While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Well, at least there's quite a few other small but useful improvements... and they showed how they really listen to the community by implementing the new syntax for passing on constructor parameters to a super-class... and by improving the docs of the 200 most popular packages with lots of examples, as requested by the people.
I like how they're listening to the community as well to implement meta-programming (like macros) [2] to solve the main pain point, currently, in Dart, which is how verbose it is to generate code for things like serialization and data types.
Once they get that, Dart will be a really good language to work on (it's already quite ok IMO, despite most people, usually those who don't actually use it much, hating on it).
[1] https://medium.com/dartlang/dart-2-17-b216bfc80c5d
[2] https://github.com/dart-lang/language/issues/1482
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
We are also working on support for pattern matching and algebraic datatype-style programming: https://github.com/dart-lang/language/blob/master/working/05...
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
We are also working on support for pattern matching and algebraic datatype-style programming: https://github.com/dart-lang/language/blob/master/working/05...
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
Any thoughts on the freezed package [0]? That's what I use currently for ADTs and exhaustive pattern matching on them, would be cool to see similar syntax in the official implementation.
[0] https://pub.dev/packages/freezed
[0] https://pub.dev/packages/freezed
It won't be that exact syntax, but, yes, the goal is to offer that kind of functionality but integrated more into the language.
That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work. I would say special syntax for it probably is critical because defining an entire class for each variant does not sound like fun!
> That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work.
It's what Scala and Kotlin do and I think it's a fairly natural mapping. (Swift takes a different approach with their enums).
> defining an entire class for each variant does not sound like fun!
If you come at it expecting the brevity of ML, yes, it's not. But if you accept that those variants are real classes and may also have their instance methods, documentation comments on the fields, etc. then the overhead starts to feel less onerous.
It's what Scala and Kotlin do and I think it's a fairly natural mapping. (Swift takes a different approach with their enums).
> defining an entire class for each variant does not sound like fun!
If you come at it expecting the brevity of ML, yes, it's not. But if you accept that those variants are real classes and may also have their instance methods, documentation comments on the fields, etc. then the overhead starts to feel less onerous.
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concept and the two only correspond with each other in the case of a sum type where each component is of a zero-arity type.
As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concept and the two only correspond with each other in the case of a sum type where each component is of a zero-arity type.
There is no real reason to have basic enums if you have ADTs , since those can easily provide everything a plain enum gives you.
I guess the name was just a historical artifact.
I guess the name was just a historical artifact.
I agree (that’s what I meant under the more expressive part), though it is a bit more complex with identity in the way. Java’s enums are also the singleton pattern.
Java recently got ADTs as well in the form of sealed classes and records, here an enum would look like this:
Java recently got ADTs as well in the form of sealed classes and records, here an enum would look like this:
sealed interface Color permits Red, Blue, Green { record Red() {}
record Blue() {}
record Green() {}
The interface implementation types may include enums, though not sure that would help much in your example.
no the feature you're looking for is sealed classes, see e.g. Kotlin.
Rust enum variants cannot be externally defined classes
That's completely orthogonal to ADT vs enum.
Enums enable two things:
check current type from union of types
and exhaustivity check in switch
The former is solved by reflection, the latter by sealed classes.
The former is solved by reflection, the latter by sealed classes.
I disagree. "Sum" and "product" types are really really unclear names that only make sense if you've studied some advanced CS and even then they're bad names - not descriptive at all.
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
Perhaps, though given that it is already used slightly differently in a very well-known language can also cause hiccups.
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like enum Option<T> { Some(T), None }
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like enum Option<T> { Some(T), None }
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.
Rust isn't alone though - Swift's `enum`s are essentially the same as Rust's enums.
I like and use Flutter myself, I recommend others use it as well if you see other comments in my profile, but one thing that annoys me is that it feels as if the major updates are coming too fast, in a way. As in, they say things like Flutter Web are now "stable" but if you actually use them, you'll find that they are clearly not stable. Windows was mentioned to be stable in the last release, but it too has issues. I am now wary of just how "stable" these macOS and Linux versions really are.
I think the marketing is getting ahead of the actual development of the framework. If parts are truly not stable, why call them stable, if not for wanting Flutter to be in the news cycle every so often?
I think the marketing is getting ahead of the actual development of the framework. If parts are truly not stable, why call them stable, if not for wanting Flutter to be in the news cycle every so often?
The Linux version is bad too.
People are talking about a better developer experience, but hardly anyone is talking about the user experience with apps built with this tech.
I don't feel it's great, especially on older devices. Take google pay, a showcase flutter app. It's a laggy mess on an iPhone SE 2016, whereas the "old" google pay ran perfectly fine. On top of that, many google apps I use these days will just freeze and stop accepting touch inputs. I have no idea if it's all flutter, or just the weird stuff google does on mobile platforms, but other apps don't suffer from this.
I think flutter is good for a resource-scarce team trying to create mobile apps for multiple platforms, but otherwise it creates an inferior end product compared to a native app (let's please not get into the definition of "native", for iOS and Android you know what I mean). For google, who has enormous developer resources, I'm not sure why they would ever use it themselves unless it's for apps they don't care about.
https://flutter.dev/showcase/google-pay
I don't feel it's great, especially on older devices. Take google pay, a showcase flutter app. It's a laggy mess on an iPhone SE 2016, whereas the "old" google pay ran perfectly fine. On top of that, many google apps I use these days will just freeze and stop accepting touch inputs. I have no idea if it's all flutter, or just the weird stuff google does on mobile platforms, but other apps don't suffer from this.
I think flutter is good for a resource-scarce team trying to create mobile apps for multiple platforms, but otherwise it creates an inferior end product compared to a native app (let's please not get into the definition of "native", for iOS and Android you know what I mean). For google, who has enormous developer resources, I'm not sure why they would ever use it themselves unless it's for apps they don't care about.
https://flutter.dev/showcase/google-pay
I'd just like to chip in with my (opposite) experience:
I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
> I semi-recently developed an app using Flutter and used an iPhone 6, a 6s, and my old Redmi Note 5 as a baseline for performance testing. While I'll admit I wasn't doing anything particularly graphics heavy (at most: sliding modals and some animations), I wasn't able to get things to dip under 60fps on either platform.
I think that's great if you're testing for performance on older phones! Many of them are still quite capable devices. I suspect google isn't doing much of this.
> As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
That's a pretty modern phone, right? Have you tried it on your 6 or 6S?
> On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I haven't, because I think the OG SE is one of the best phones ever made. And I'm not a phone power user in the sense that I'm gaming on it, or doing lots of graphically intensive things. I just replaced the battery on it after using it for 5 years, and it runs everything I want to do perfectly...with the exception of google pay and some of google's other apps.
The issue I have with these basic CRUD apps running with tons of jank is that they're essentially just a UI with some text labels and buttons. For google pay, I want to open it up, navigate a list of people, select one, enter a number, and press "Pay". A computer from the 80s could do this no problem, it's not a graphically or computationally demanding thing. Certainly a computer from 2016 (iPhone SE) is up to the task, and before the google pay transition to flutter, it totally was.
Creating this software that runs slower, with no tangible end-user benefits, is simply pushing us towards more e-waste as people upgrade their devices unnecessarily.
I think that's great if you're testing for performance on older phones! Many of them are still quite capable devices. I suspect google isn't doing much of this.
> As for the GPay app, the only performance issue I could notice from testing just now was a dropped frame while quickly scrolling through the "explore" page. Otherwise it works perfectly on my Z Flip 3.
That's a pretty modern phone, right? Have you tried it on your 6 or 6S?
> On the other hand - have you considered upgrading devices? I always hate whipping out the iPhone 6s (same A9 CPU as your SE) because it runs like hot garbage in most cases... a recurring theme in the iOS space.
I haven't, because I think the OG SE is one of the best phones ever made. And I'm not a phone power user in the sense that I'm gaming on it, or doing lots of graphically intensive things. I just replaced the battery on it after using it for 5 years, and it runs everything I want to do perfectly...with the exception of google pay and some of google's other apps.
The issue I have with these basic CRUD apps running with tons of jank is that they're essentially just a UI with some text labels and buttons. For google pay, I want to open it up, navigate a list of people, select one, enter a number, and press "Pay". A computer from the 80s could do this no problem, it's not a graphically or computationally demanding thing. Certainly a computer from 2016 (iPhone SE) is up to the task, and before the google pay transition to flutter, it totally was.
Creating this software that runs slower, with no tangible end-user benefits, is simply pushing us towards more e-waste as people upgrade their devices unnecessarily.
Is this really Flutter's fault or is it Google's?
Google doesn't even support its own devices from 2016, so I doubt they'd optimize their apps for the iPhone SE 2016.
Google doesn't even support its own devices from 2016, so I doubt they'd optimize their apps for the iPhone SE 2016.
Its equally bad on Google's flagship Pixel 6 Pro. There are three tabs in the gPay app and its about 2FPS as it animates between the tabs. Scrolling is janky.
Keeping the baseline/core running smooth and efficient helps every device and every app, so they don't need to optimize for iphone se 2016 per se.
Googler, opinions are my own.
Interesting thread from a year ago may interest you: https://news.ycombinator.com/item?id=26333973 (it's a flutter lead talking about Google pay).
I'd be interested to know how much the team tests with an iphone that old.
Interesting thread from a year ago may interest you: https://news.ycombinator.com/item?id=26333973 (it's a flutter lead talking about Google pay).
I'd be interested to know how much the team tests with an iphone that old.
I find Google’s iOS apps to be thoroughly mediocre and frustrating to use, whether they’re Flutter or not. They just don’t behave like iOS apps.
It’s even worse when you’re in a less common set up, like using an iPad with a keyboard case. I can’t even use the arrow keys to move between search results in the YouTube app.
I know most people don’t care, but it’s the endless little details that make me thoroughly dislike cross-platform toolkits.
It’s even worse when you’re in a less common set up, like using an iPad with a keyboard case. I can’t even use the arrow keys to move between search results in the YouTube app.
I know most people don’t care, but it’s the endless little details that make me thoroughly dislike cross-platform toolkits.
[deleted]
I was hoping to see better HTML rendering. Using a single canvas to render web apps was my one turn off. Flutter is the right choice for many apps, but not for apps primarily accessed over the Web.
It is not production ready for web and I don't have much hope it ever will be. I love it for mobile, even desktop apps. But I feel they chose the wrong direction at the beginning for web and it's just trying to dig back out of that hole since then.
Couldn't they just embed Chrome, like Electron did?
For desktop and mobile, Flutter renders over OpenGL, why do they need to embed chrome ?
The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.
The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.
IMO it's most useful for more compute intensive web apps like an image editor.
What’s wrong with using a single canvas? It can be faster. Google Docs and Figma, for example, use canvas rendering
Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at.
Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too.
It's a huge trade-off to make, and something to be aware of.
Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too.
It's a huge trade-off to make, and something to be aware of.
Heavy emphasis on HUGE tradeoff. Too much for most web apps, IMO.
I just checked and Google Docs is not a single canvas. It uses a canvas for the text but all the tools and so on are good old html.
Believe it’s a work in progress https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
> What’s wrong with using a single canvas
You can't even select and copy text. And canvas is inaccessible to screen readers
You can't even select and copy text. And canvas is inaccessible to screen readers
FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too.
wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.
We're using Flutter for mobile development at my workplace.
[1] https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-local...
wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.
We're using Flutter for mobile development at my workplace.
[1] https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-local...
For accessibility they create a separate DOM tree just for screen readers.
This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
Just as an FYI that is how the official web spec works https://wicg.github.io/aom/spec/
I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
I believe the spec you link is a future proposal at the moment. And I trust a consortium of folks from a variety of browser vendors along with folks from other interests over a single product, when it comes to trying to figure out a better way to make things more accessible. And maybe Flutter can just use AOM in the future when it's available in browsers.
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
Are there declarative and performant ways to synchronize a canvas with a DOM tree? Maybe the answer here is obvious but this seems like quite a bit of overhead, both for developers and the browser.
Do they need to be synchronized? I can’t imagine that a screen reader would be sensitive to millisecond-level discrepancies between canvas updates and DOM updates.
I’m not concerned about the delay between updates, it’s the correctness of the DOM and the canvas and managing interactions between the two. I might be misunderstanding the problem (or lack thereof) because I haven’t dealt with accessibility and canvas.
When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc?
How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this.
My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc?
How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this.
My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
at this point you'd better get rid of the canvas
Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features).
Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.
For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.
Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.
For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.
Both Google docs and figma use canvases, but neither of them renders the whole app through a canvas.
This is easy to verify - just open up dev tools and look at the DOM structure.
This is easy to verify - just open up dev tools and look at the DOM structure.
Both are pretty disastrous accessibility-wise.
no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.
Canvas has accessibility issues for screen readers as well as for SEO purposes.
We have a react native app and sometimes it fails to build. We go to lunch, and come back no code change now it builds.
I'm just sick of the NPM/Javascript bullshit.
Does Flutter avoid all of these kinds of issues? I'm this close to scrapping the whole thing.
I'm just sick of the NPM/Javascript bullshit.
Does Flutter avoid all of these kinds of issues? I'm this close to scrapping the whole thing.
I worked with React Native for 3 years before jumping over to Flutter and this was the biggest reason why I made the switch. Its exponentially better on Flutter. The only time builds break for the team are when we made a code change that broke it. Its consistent and non-flaky (looking at you RN). Not that you won't run into the occasional issue but with React Native easily 20% of my time developing was "this just stopped working and there's no reason why". React Native was configuration hell. With Flutter, I haven't struggled with that at all past the initial setup.
This has been my experience with RN too (admittedly, a few years back). So much time wasted on troubleshooting random glitches that occur for seemingly unrelated reason. Some minor library version update? Boom, your breakpoints no longer work. Why? Noone knows. The "turn it off, turn it on" approach seems to be the go-to fix in this environment. And there's always another surprise around the corner.
I can't really contrast it with Flutter, because I only toyed with it a little bit, but at least the docs were of much better quality - and this being a few years back as I said, the fact that Flutter was the newer framework (and still provided better quality at least in this area) was even more pronounced.
I never coded React Native, but I have a lot of experience with Flutter. You can definitely run into build issues, but it's almost exclusively when doing precarious things like upgrading third party packages, SDKs or Flutter versions. As soon as you've traversed the depths of dependency hell and it builds, it builds without a hitch repeatedly in my experience.
As the framework is maturing there have been some major transitions between APIs and project structure. My main app that was scaffolded two years ago has had no shortage of duct tape fixes and tweaks to especially Gradle/Cocoapods config to keep it building.
I guess it's a fair price for what has otherwise been a fantastic developer experience. All in all I'd strongly recommend it.
As the framework is maturing there have been some major transitions between APIs and project structure. My main app that was scaffolded two years ago has had no shortage of duct tape fixes and tweaks to especially Gradle/Cocoapods config to keep it building.
I guess it's a fair price for what has otherwise been a fantastic developer experience. All in all I'd strongly recommend it.
As someone with a lot of Flutter experience, I can second this. It usually works pretty reliably until someday you upgrade and cocoapods keeps complaining even when you clean everything and rebuild.
There is no framework that never has issues.
Flutter has its fair share (and to be fair, so do the native toolchains).
Flutter has its fair share (and to be fair, so do the native toolchains).
For mobile apps (not web), I think yes - Flutter solves a lot of these kinds of issues. As with any project, don't just blindly add a lot of dependencies as they may vary in quality and stability, but overall you deal with two things; Dart and Flutter, and it's quite refreshing.
Not as good as native, but if you're going to go cross platform due to various reasons such as development costs, then it's the way to go.
Not as good as native, but if you're going to go cross platform due to various reasons such as development costs, then it's the way to go.
> I'm just sick of the NPM/Javascript bullshit.
Amen
Amen
Flutter is miles ahead of React Native at least in this regard
No, use native if you want to avoid that
In case any Flutter engineer/PM is watching this thread, any update on when the Material 3 components will be released?
I have an iOS Flutter app that's getting pretty popular in its niche, but I'm waiting on the Material 3 components to be there to release an Android version.
I have an iOS Flutter app that's getting pretty popular in its niche, but I'm waiting on the Material 3 components to be there to release an Android version.
For a list of what is currently available in Flutter 3, as well as a roadmap of upcoming features, see the M3 umbrella issue:
https://github.com/flutter/flutter/issues/91605
Feel free to upvote any issue that you would like to see prioritized, as it helps us with planning.
https://github.com/flutter/flutter/issues/91605
Feel free to upvote any issue that you would like to see prioritized, as it helps us with planning.
[deleted]
That was part of the release today I believe.
Maybe I missed it? It seems like they got some working but got a bunch on their roadmap still [0]. I just talked to someone over there and all he could say is that they're working on it.
[0] https://github.com/flutter/flutter/issues/91605
[0] https://github.com/flutter/flutter/issues/91605
Congrats! Flutter is such an amazingly crazy concept that when I started my current job it was on the condition that I could learn and use it for our app. I'm not regretting it in the slightest. In fact I get more impressed with it the more I use it. Great job!
I still can't find, in the docs, there is an open bug/feature request to NATIVELY copy/paste from web?
Do they support copy / paste on the web app without using a special widget?
Do they support copy / paste on the web app without using a special widget?
I'm not aware of any planned/possible way to do copy exactly as you would an HTML page with HTML tags, but there's a big project to make selection and copying much simpler and more powerful (design doc [1], in progress PR[2]).
With that PR it should be easy to just add one SelectionArea to the root of your app in order to make everything selectable, like it would be on a web page. You don't need SelectableText widgets. There's an example of this in the PR [3]. No built-in support for multimedia or rich text copying yet though.
Text input fields should already do copy/paste pretty much the same as native.
[1] http://flutter.dev/go/global-selection [2] https://github.com/flutter/flutter/pull/95226 [3] https://github.com/flutter/flutter/pull/95226/files#diff-a90...
With that PR it should be easy to just add one SelectionArea to the root of your app in order to make everything selectable, like it would be on a web page. You don't need SelectableText widgets. There's an example of this in the PR [3]. No built-in support for multimedia or rich text copying yet though.
Text input fields should already do copy/paste pretty much the same as native.
[1] http://flutter.dev/go/global-selection [2] https://github.com/flutter/flutter/pull/95226 [3] https://github.com/flutter/flutter/pull/95226/files#diff-a90...
Great initiative. Wondering why can't Google make this a priority and make it fast instead of focus on desktop and other device support.
Do they know that a ton of devs are not jumping in because of this one simple issue and sticking to other frameworks?
Do they know that a ton of devs are not jumping in because of this one simple issue and sticking to other frameworks?
Kind of crazy all this effort is being put into just recreating something that has been around, and works fine, for 20 years. What a waste of resources.
Does Flutter have a complete Material UI components implementation? I'd prefer to use Flutter for multi-platform support over learning new Android Compose and figuring out what to do for other platforms later.
Does anything have a complete Material components implementation?
I always got the vibe from Material that it's just a bunch of designers pumping out docs for an ideal world, and then the various libraries try to implement a bunch of those things as they change faster than they can be implemented.
I always got the vibe from Material that it's just a bunch of designers pumping out docs for an ideal world, and then the various libraries try to implement a bunch of those things as they change faster than they can be implemented.
Indeed. It wasn't that long ago that Material components for Android finally got proper support for Material 2 in a stable release of the library. But everything started too look too nice and consistent, so now we're getting steamrolled with Material 3.
Yes, there are two default widget packages, Cupertino and Material.
https://docs.flutter.dev/development/ui/widgets/material
https://docs.flutter.dev/development/ui/widgets/material
I'm not sure I can say it's complete but it's better than Android in my experience. There's also more built for you already, like button styles and page layouts.
It’s built right into it. Both material 2 and 3.
I have been working on a Hacker News client using Flutter, if anyone is interested:
https://github.com/Livinglist/Hacki
https://github.com/Livinglist/Hacki
Thanks for sharing! The design looks really slick.
As a hobbyist Flutter developer who hasn't figured out how to make Flutter apps look remotely appealing yet, it's been cool poking around your code and trying to learn from it. Bloc and Cubit look especially interesting.
As a hobbyist Flutter developer who hasn't figured out how to make Flutter apps look remotely appealing yet, it's been cool poking around your code and trying to learn from it. Bloc and Cubit look especially interesting.
thanks! here’s another Hacker News client made with Flutter from another dev that has a much better looking UI, but it is only available on FDroid. (though you can build it yourself for iOS):
https://github.com/Mosc/Glider
https://github.com/Mosc/Glider
On one hand, I'm excited, on the other hand, I'm using a Flutter app right now as essentially a utility for my own personal use.
I'm horrified if I upgrade it everything will break and I'll have to commit to fixing it.
Still, I'm very excited about this, I'd argue flutter is what react native wanted to be.
I'm horrified if I upgrade it everything will break and I'll have to commit to fixing it.
Still, I'm very excited about this, I'd argue flutter is what react native wanted to be.
Not sure if you’re new to the Flutter / Dart ecosystem but one of the nice advantages that comes as a side effect of having “Google scale” backing it is how nice the upgrade experience is.
Generally you just run a single command of dart fix and it will statically analyse the code and automatically rewrite anything that’s outdated to use the latest syntax for you.
https://dart.dev/tools/dart-fix
Generally you just run a single command of dart fix and it will statically analyse the code and automatically rewrite anything that’s outdated to use the latest syntax for you.
https://dart.dev/tools/dart-fix
I'll consider it, but I really really don't want to invest more time into fixing things.
Like it's essentially finished. Then again, I can always branch it and see what happens.
Like it's essentially finished. Then again, I can always branch it and see what happens.
Shout out to the Net Ninaja's Flutter tutorial: https://youtube.com/playlist?list=PL4cUxeGkcC9jLYyp2Aoh6hcWu...
Just the best. No affiliation.
Just the best. No affiliation.
What are big and highly used apps that use Flutter?
My app[1] has 5 figure daily users (if that's considered somewhat big) and is written in Flutter.
I love Flutter. It made all this so much easier.
[1] https://stockevents.app
I love Flutter. It made all this so much easier.
[1] https://stockevents.app
This is really nice for testing. It uses most of the pretend-native components I was interested in.
Right off the bat, I notice stuttering animations everywhere: Scrolling, swiping back, etc... This is on an iPhone 13.
In one section, the keyboard opened on top of a text-field so I couldn't see what I was typing.
The components are _just_ different enough that I feel something is wrong, but for the most part, I can't tell what it is.
Then there's a bunch of minor stuff. Switches become slightly larger when they change. You cant swipe down modals. You can't drag & release over options in the sheet. I feel like I'm missing buttons more often.
Overall, I get a vague cheap feel. Not so bad that I would outright dismiss the app as a customer, but I would definitely look for alternatives.
This isn't a critique of the app. I think all of these issues are flutter-related.
Right off the bat, I notice stuttering animations everywhere: Scrolling, swiping back, etc... This is on an iPhone 13.
In one section, the keyboard opened on top of a text-field so I couldn't see what I was typing.
The components are _just_ different enough that I feel something is wrong, but for the most part, I can't tell what it is.
Then there's a bunch of minor stuff. Switches become slightly larger when they change. You cant swipe down modals. You can't drag & release over options in the sheet. I feel like I'm missing buttons more often.
Overall, I get a vague cheap feel. Not so bad that I would outright dismiss the app as a customer, but I would definitely look for alternatives.
This isn't a critique of the app. I think all of these issues are flutter-related.
Just trying to be honest here, but using this as an example on my iPad Pro with magic keyboard... flutter apps do not feel great on iOS IMO. Animations have an initial low fps/jerkyness to them. Lot of weirdness when trying to use an the iPad trackpad, horizontal directions seem to be inverted. Scrolling inertia and feel just feels off in general to me. I'm sure flutter is great on Android and all but it still feels like they have a bit of work to do on iOS in order to really cross that uncanny valley gap.
Regardless I'm sure what you have is a great app here so hope you don't feel like I'm targeting you or your app directly here, and at the end of the day if flutter allows you to make your customers happy more power to you and hope it works out the best for you.
Regardless I'm sure what you have is a great app here so hope you don't feel like I'm targeting you or your app directly here, and at the end of the day if flutter allows you to make your customers happy more power to you and hope it works out the best for you.
Your app looks good! I'm curious, what did you use for the charts?
My app [0] isn't big, but it's highly rated and uses Flutter
[0] https://apps.apple.com/us/app/five-three-one/id1560266240
[0] https://apps.apple.com/us/app/five-three-one/id1560266240
Do you have an Android version?
Not yet. I'm waiting to use the Material 3 components which hopefully should be out soon.
Doesn't appear to based on the website, which is just sad considering it's almost zero effort to create an Android build as well. I'd consider using this app also.
I could indeed build it for Android, but since I'm using the Cupertino components, it would look and feel like an iOS app. As I said replying to the parent comment, I'm currently waiting on the Material 3 components to be available before I do that.
Sounds good, although a bit sad I can't try it out, even if it felt more iOS-like. But you gotta prioritize your app and what's best for it. Good luck!
Philips Hue is fully Flutter since a while now (v4). There were issues with (pre-rendering of) animations but those have been resolved in Flutter.
Google Home is the first thing that comes to mind.
See here: https://flutter.dev/showcase
See here: https://flutter.dev/showcase
From all those apps Google Home is the only I had to use for my Google Wifi router and it crashed a bunch of times!
It's very spotty connecting to my Chromecast as well, but the UI is cool!
Home is so buggy on my iPhone, it's strange that it's part of the showcase.
Google home is my most-hated mobile app. It’s slow, janky, buggy, and has terrible UX.
Every action requires waiting. Its so frustrating. Open the app, spinner. Click themostat, spinner. Change the temperature, spinner. Its so frustrating. I use Home Assistant now as my primary home control app.
I just noticed that. Opening the Settings menu shows a spinner! Are they downloading the list of settings items from the internet?!!
Our app probably falls into those categories. Millions of downloads between iOS and Android, and has upwards of 50 different pages.
iOS: https://apps.apple.com/us/app/tracker-network-stats/id128769... Android: https://play.google.com/store/apps/details?id=network.tracke...
iOS: https://apps.apple.com/us/app/tracker-network-stats/id128769... Android: https://play.google.com/store/apps/details?id=network.tracke...
They have a showcase page that details large brands that use Flutter: https://flutter.dev/showcase
There's also there own website: https://itsallwidgets.com/
Canonical have specified it as the default development tool for their apps (e.g. the Ubuntu installer)
Nubank’s mobile apps are built using Flutter. They’re the largest neobank in LATAM (>50MM customers).
Google Ads uses it on mobile which is responsible for literally billions in revenue.
I believe the Sonos mobile app is Flutter.
Coming from a django/python background, flutter/dart was easier to understand than react/js. It has been fun to work with, esp. with Vscode and extensions, on a side project.
Flutter is a mature option for mobile development, esp. for small teams developing for multiple platforms.
Flutter is a mature option for mobile development, esp. for small teams developing for multiple platforms.
Any plans to make it possible to embed Flutter in existing desktop applications?
Especially for use in plugins to existing said that do not control the main event loop?
Especially for use in plugins to existing said that do not control the main event loop?
as an early and aggressive adopter of Google tech it was completely infuriating to watch them announce Flutter + Firebase integration as if it was new or interesting.
that should have been working day 1. maybe day 2. flutter has been out for years, and the fact that you can’t successfully use Google software with Google’s other software is starting to be a wart they can’t excuse because of internal build chain differences.
that should have been working day 1. maybe day 2. flutter has been out for years, and the fact that you can’t successfully use Google software with Google’s other software is starting to be a wart they can’t excuse because of internal build chain differences.
+1 for Flutter 3 supports the Apple Silicon Mac (aka M1).
I could not get this to run on a Ubuntu VM (arm64) - anyone know if this is also working?
I could not get this to run on a Ubuntu VM (arm64) - anyone know if this is also working?
Works fine for me in Asahi Linux, both Flutter 2.x and after upgrading to 3.
Really using Asahi as a daily driver? Thought it didn't have video acceleration yet?
Ha nope, just occasionally playing around with it. No video acceleration, but still usable for web browsing and development. It's amusing to drag a window around and see all the CPU cores spike to 100% as they frantically pretend to be a GPU.
did they fix the scrolling on iOS?
From their What’s New: “ Flutter now supports variable refresh rate on iOS devices with ProMotion displays, including iPhone 13 Pro and iPad Pro. On these devices, Flutter apps can render at refresh rates reaching 120 hz, which were previously limited to 60 hz. This results in a smoother experience during fast animations such as scrolling. See flutter.dev/go/variable-refresh-rate for more details.”
can does not mean it will.
Not yet, but they have a beta thing that you can enable to smooth that out
> Impeller precompiles a smaller, simpler set of shaders at engine build time so that they won’t compile while an app is running; this has been a major source of jank in Flutter.
> Impeller precompiles a smaller, simpler set of shaders at engine build time so that they won’t compile while an app is running; this has been a major source of jank in Flutter.
if they disable the shader jit it will result in much worse performance overall
Yet another reason to avoid cross platform frameworks. They are always catching up to the vendor’s capabilities.
That is a reason to avoid cross platform frameworks. But there are big reasons in favour of using then as well. It's a trade-off depending on your use case.
For the vast majority of (mobile) apps, the benefit of being able to be built from a single code base outweighs being slightly behind vendor capabilities. Particularly things like there where it doesn't come up in some apps and relatively few people actually notice/care about it in those it does.
Google doesn’t think it’s own cross platform framework is good enough for its own applications
https://9to5google.com/2021/10/10/google-ios-apps-native/
https://9to5google.com/2021/10/10/google-ios-apps-native/
> The company’s official guidance to past developer users is to “follow Apple’s Human Interface Guidelines and consider using modern UIKit components or SwiftUI instead.” That said, it also plugged Flutter as the way to “get a Material look and feel across all platforms.”
Doesn't seem like the article you linked accurately represents your statement.
Doesn't seem like the article you linked accurately represents your statement.
So Google recommending Apple’s native framework is not encouraging people to use Apple’s native frameworks?
This wasn’t anything to do with Futter for the record and they even called it out in a quote saying that they continue to recommend Flutter in that article.
They continue to recommend it for other developers. But it isn’t good enough for them?
And typical Google
> As part of this shift, Google in July put Material’s iOS libraries in “maintenance mode.”
Who is to say Flutter isn’t next? Google has the attention span of a coked up teenager.
And typical Google
> As part of this shift, Google in July put Material’s iOS libraries in “maintenance mode.”
Who is to say Flutter isn’t next? Google has the attention span of a coked up teenager.
I haven’t really had a great experience with Flutter in the past, in my opinion I think React Native provides a better user experience. Developer experience is okay.
The best experience for users would be a library that handles business logic, as well as describes how the UI should be laid out, then building native clients that use that library.
The best experience for users would be a library that handles business logic, as well as describes how the UI should be laid out, then building native clients that use that library.
Sorry for the very newbie question. Can someone compare this with let's say an Electron + React approach ?
Flutter is great for cross-platform UIs.
I found it a bit difficult to work with, and I also wanted to code my UIs from the back-end. So I wrote DocUI which will be released in the next month or two. https://nexusdev.tools
I found it a bit difficult to work with, and I also wanted to code my UIs from the back-end. So I wrote DocUI which will be released in the next month or two. https://nexusdev.tools
@tosh submits a great amount of posts. Most do not reach a great audience but a number do, and he has gained a large amount of points in a short time (despite being from 2010 he has only started this mass-posting recently). What's that about?
Happy paths not found… https://docs.flutter.dev/development/platforms-and-plugins/h...
Fixed! Thanks
It's: https://docs.flutter.dev/development/packages-and-plugins/ha...
It's: https://docs.flutter.dev/development/packages-and-plugins/ha...
This works for me:
https://docs.flutter.dev/development/packages-and-plugins/ha...
Can Flutter/Dart dynamically load code yet for apps that need plugins?
Love the concept but eyeing it for b2b style apps that need extensibility.
Love the concept but eyeing it for b2b style apps that need extensibility.
Depends on what you mean exactly. But you can split dynamically load code (all uploaded at once to the Play Store) via https://docs.flutter.dev/perf/deferred-components
I wish flutter3 would be simple and lean C which does not require a grotestquely and absurdely massive and complex c++ compiler.
Did dart eventually add sum types? That's basically the one thing holding me from trying flutter.
Not yet but they're apparently working on it:
https://news.ycombinator.com/item?id=31346426
Question: can you write a de-googled flutter app?
Or does it require google services or call home monitoring
Or does it require google services or call home monitoring
Question: can you write a de-googled flutter app?
Yes, there's several in F-droid. Flutter doesn't use any Google services by default.
Yes, there's several in F-droid. Flutter doesn't use any Google services by default.
Flutter is great, hope the update doesn't break too much!
so...anybody using it to build web apps in lieu of react?
Something Google V3 actually exists?
Honestly I think browsers (desktop and mobile) will implement native apis faster than these things will implement native apis.
TLDR: JavaScript and browser apis will win in the end.
TLDR: JavaScript and browser apis will win in the end.
I use Flutter as a way to host a sqlite and business logic and render all UI in a local webview for this reason. Just testing now, but works OK.
It's already the case, Cordova/Ionic has much more native plugins than react native and flutter combined!
https://www.npmjs.com/search?q=ecosystem%3Acordova
It's only a matter of time before people realize how superior Ionic is, and I can't wait for people to realize Ionic is faster and more energy efficient too!
https://ionicframework.com/blog/ionic-vs-react-native-perfor...
I have an irrational annoyance when projects claim to support "desktop UI" but then only have the most trivial of widgets commonly used in desktop applications. Where is my tree view? Data grid view? Charts? Native file dialog window?
From my perspective, while I'm sure Flutter is wonderful, it fits squarely in the "mobile" UI toolkit and "basic" desktop application category.
From my perspective, while I'm sure Flutter is wonderful, it fits squarely in the "mobile" UI toolkit and "basic" desktop application category.
Hey there! I work on Flutter for desktop. I'm happy to provide a little background.
We made a decision early on to focus where those of us who work on Flutter could deliver the most value, and for Desktop that meant getting the runtimes and platform integration for each of the desktop OSes in good shape (international text input, accessibility support, rendering performance, etc.) as well as core integrations like the menu bar, file chooser dialogs, etc. These are things that need to land in the runtime itself and are significantly more painful for the community to contribute, or author and publish on pub.dev.
We're working on filling in the gaps for widgets that are part of the Material spec, and I expect the community to make and publish widgets on pub.dev that continue to surprise me; I'm blown away time and time again at the beautiful widgets and the community continues to produce either in packages or as pull requests. You should be able to find community-authored packages for treeview, datagrid, and charting on pub.dev today in the meantime.
We made a decision early on to focus where those of us who work on Flutter could deliver the most value, and for Desktop that meant getting the runtimes and platform integration for each of the desktop OSes in good shape (international text input, accessibility support, rendering performance, etc.) as well as core integrations like the menu bar, file chooser dialogs, etc. These are things that need to land in the runtime itself and are significantly more painful for the community to contribute, or author and publish on pub.dev.
We're working on filling in the gaps for widgets that are part of the Material spec, and I expect the community to make and publish widgets on pub.dev that continue to surprise me; I'm blown away time and time again at the beautiful widgets and the community continues to produce either in packages or as pull requests. You should be able to find community-authored packages for treeview, datagrid, and charting on pub.dev today in the meantime.
With limited resources you have to choose. If flutter focused on UI elements before Mac OS + Linux stability, the top comment would be "Flutter is a solid option for Windows but without Linux or Mac support it is useless."
The flutter team has proven generally capable of developing UI elements on mobile across iOS/Android. Getting platform stability is a welcome step and i trust them to continue to build out the desktop element set.
Flutter has been my go-to for mobile app dev for years and i haven't considered returning to react native, pure native or cordova since i swapped.
All that being said, i have spent my afternoon debugging an issue with Flutter's first-party camera plugin, so it isn't all roses.
The flutter team has proven generally capable of developing UI elements on mobile across iOS/Android. Getting platform stability is a welcome step and i trust them to continue to build out the desktop element set.
Flutter has been my go-to for mobile app dev for years and i haven't considered returning to react native, pure native or cordova since i swapped.
All that being said, i have spent my afternoon debugging an issue with Flutter's first-party camera plugin, so it isn't all roses.
Even Apple's own declarative SwiftUI framework looks like it trails far behind covering rich, comprehensive AppKit apps: https://developer.apple.com/documentation/swiftui/building_a....
You can integrate appkit components into a swiftui app though.
This is a big gripe I have with WinUI. How on earth do you create a desktop UI framework that lacks something as basic as a tableview/data grid… it's only slightly less bad than a UI framework not having a button widget. One should not need to import a third party dependency or write your own for something so basic.
I'd love to see a "Back to the Future" desktop UI toolkit that has roughly the capabilities of AppKit circa 2003 but in a modern language, clean unified API, cross-platform, with seamless native UI integration, and of course not carrying hundreds of megabytes of Chromium gunk in each app like Electron does.
That would be wonderful. AppKit is the closest to perfect I've found in desktop UI frameworks. If it took some of the improvements found in UIKit and was cross platform I'd never use anything else.
not carrying hundreds of megabytes of Chromium gunk in each app like Electron does.
this problem has been solved multiple times, see e.g. Tauri
Well I think all of these widgets are available on pub.dev. For example, I'm using the charts_flutter plugin: https://google.github.io/charts/flutter/gallery.html
I think a tree view was promised (listed on a presentation) when Flutter 2.0 was released, but no details were provided, and I haven't heard of it ever since.
You might be thinking of this package, authored by Google, mostly by people on the Flutter team but it's not an official Flutter project (as far as I know): https://pub.dev/packages/flutter_simple_treeview
(Disclaimer: I work on the Flutter team.)
(Disclaimer: I work on the Flutter team.)
who builds desktop applications anymore? it feels weird to say but i am starting to like them again after transitioning to basically 100% thin client/cloud services for the past 15 years.
I’m confused, do you not use desktop apps?
How many new desktop apps do you use (first released in the past ~5 years or so), and how many of them aren't Electron?
Desktop GUI software is a pretty small niche. The web has eaten nearly everything, and games don't use native UI stuff.
Desktop GUI software is a pretty small niche. The web has eaten nearly everything, and games don't use native UI stuff.
The post I replied to implied that the rate of production of them is decreasing, and you are claiming this too. I’m not convinced about that.
yes, the only market for new apps would be CLI, games and scientific computing/technical niches
I did in the early days when the web sucked, then dhtml and web2.0 started and I completely swapped. Now I'm starting to again. I like them more the web apps. But no one is making them anymore
What qualifies as a "desktop application" these days?
Is it any application designed primarily to work on a laptop or desktop form factor? A web application like SketchUp would qualify.
Is it an application whose code is only stored locally, even if they don't work well with a laptop/desktop form factor? Any number of native mobile apps would qualify.
What about a PWA that is cached locally but initially loaded via a URL?
Is it any application designed primarily to work on a laptop or desktop form factor? A web application like SketchUp would qualify.
Is it an application whose code is only stored locally, even if they don't work well with a laptop/desktop form factor? Any number of native mobile apps would qualify.
What about a PWA that is cached locally but initially loaded via a URL?
I don't consider electron apps or any thin veneer over some javascript to be a desktop app.
I also don't consider native phone/tablet apps to be desktop apps
I also don't consider native phone/tablet apps to be desktop apps
> I don't consider electron apps or any thin veneer over some javascript to be a desktop app.
So VSCode isn't a desktop app?
So VSCode isn't a desktop app?
[deleted]
Does anybody know of any good Flutter for Windows applications that are worth looking at?
Rows [0], a spreadsheet app, has its Windows and macOS versions built in Flutter. It's quite fast from my usage. The marketing video they did for Flutter [1] goes into a little detail as to how they did it but they also have a tech talk that goes into more detail [2]. Their spreadsheet engine is open source as well [3].
[0] https://rows.com/download
[1] https://www.youtube.com/watch?v=OEdQXBUPYOE
[2] https://www.youtube.com/watch?v=fv_mzbEtUmU
[3] https://github.com/rows/swayze
[0] https://rows.com/download
[1] https://www.youtube.com/watch?v=OEdQXBUPYOE
[2] https://www.youtube.com/watch?v=fv_mzbEtUmU
[3] https://github.com/rows/swayze
Same question, do they have a reasonable component library on windows?
and rendering benchmarks
Figure out JSON de/serialization yet?
Just make a class and generate helper methods /s
I know this was sarcasm, but sadly, it is one of the better ways to handle this.
[deleted]
Google Flutter Team: You launched Flutter Desktop and got your promotions. Now can you please go back and finish Flutter Mobile? Specifically, please add:
- Integration testing [0, 1]
- Location [2]
- iOS dark mode [3, 4]
- iOS keyboard dismiss decoration [5]
- iOS keyboard scroll-to-dismiss mode [6]
- iOS NavigationLink widget [7]
- iOS checkbox widget [7]
- Android camera that doesn't randomly crash (unfixed for 3 years) [8]
- Android date-time picker (Requested in email to Flutter Team. They refused.)
- Usable documentation for Navigator 2.0 [9, 10]
- Debugger visibility into Dart async tasks
- Stop HTTP requests on timeout [11]
- Testing on physical devices for apps that use flavors [12]
- UI inspection tools that don't randomly stop working
EDIT: Added bug links.
[0] https://github.com/flutter/flutter/issues/88549
[1] https://github.com/flutter/flutter/issues?q=is%3Aissue+comme...
[2] https://github.com/flutter/flutter/issues/31453
[3] https://github.com/flutter/flutter/issues/48438
[4] https://github.com/flutter/flutter/issues/80860
[5] https://github.com/flutter/flutter/issues/45076
[6] https://github.com/flutter/flutter/issues/57609
[7] https://docs.flutter.dev/development/ui/widgets/cupertino
[8] https://github.com/flutter/flutter/issues/70751
[9] https://github.com/flutter/flutter/issues/69315
[10] https://github.com/flutter/flutter/issues/81610
[11] https://github.com/dart-lang/http/issues/424
[12] https://github.com/flutter/flutter/issues/99607
- Integration testing [0, 1]
- Location [2]
- iOS dark mode [3, 4]
- iOS keyboard dismiss decoration [5]
- iOS keyboard scroll-to-dismiss mode [6]
- iOS NavigationLink widget [7]
- iOS checkbox widget [7]
- Android camera that doesn't randomly crash (unfixed for 3 years) [8]
- Android date-time picker (Requested in email to Flutter Team. They refused.)
- Usable documentation for Navigator 2.0 [9, 10]
- Debugger visibility into Dart async tasks
- Stop HTTP requests on timeout [11]
- Testing on physical devices for apps that use flavors [12]
- UI inspection tools that don't randomly stop working
EDIT: Added bug links.
[0] https://github.com/flutter/flutter/issues/88549
[1] https://github.com/flutter/flutter/issues?q=is%3Aissue+comme...
[2] https://github.com/flutter/flutter/issues/31453
[3] https://github.com/flutter/flutter/issues/48438
[4] https://github.com/flutter/flutter/issues/80860
[5] https://github.com/flutter/flutter/issues/45076
[6] https://github.com/flutter/flutter/issues/57609
[7] https://docs.flutter.dev/development/ui/widgets/cupertino
[8] https://github.com/flutter/flutter/issues/70751
[9] https://github.com/flutter/flutter/issues/69315
[10] https://github.com/flutter/flutter/issues/81610
[11] https://github.com/dart-lang/http/issues/424
[12] https://github.com/flutter/flutter/issues/99607
I think a lot of these comments are not necessarily valid or have been addressed already and we've lost the actual productive feedback in the mess.
- Integration testing - This exists and is very commonly used: https://docs.flutter.dev/cookbook/testing/integration/introd...
- Location - This 100% should be a core offering, its crazy that its not for mobile application.
- iOS dark mode - Flutter supports Dark Mode - https://api.flutter.dev/flutter/material/ThemeMode.html
- iOS keyboard dismiss decoration - Not sure on this.
- iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
- iOS NavigationLink widget - Not familiar with this construct but easy to build yourself.
- iOS checkbox widget - Totally agree but also easy to build directly.
- Android camera that doesn't randomly crash (unfixed for 3 years) - We've got a couple application that use camera and never had this issue.
- Android date-time picker - This has been in for a long time: https://api.flutter.dev/flutter/material/showDatePicker.html
- Usable documentation for Navigator 2.0 - I think the updated docs on navigation have addressed this issue largely.
- Debugger visibility into Dart async tasks - You can 100% debug async tasks.
- Stop HTTP requests on timeout - This exists in Flutter https://stackoverflow.com/a/51489701
- Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
- UI inspection tools that don't randomly stop working - Never had this happen.
- Integration testing - This exists and is very commonly used: https://docs.flutter.dev/cookbook/testing/integration/introd...
- Location - This 100% should be a core offering, its crazy that its not for mobile application.
- iOS dark mode - Flutter supports Dark Mode - https://api.flutter.dev/flutter/material/ThemeMode.html
- iOS keyboard dismiss decoration - Not sure on this.
- iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
- iOS NavigationLink widget - Not familiar with this construct but easy to build yourself.
- iOS checkbox widget - Totally agree but also easy to build directly.
- Android camera that doesn't randomly crash (unfixed for 3 years) - We've got a couple application that use camera and never had this issue.
- Android date-time picker - This has been in for a long time: https://api.flutter.dev/flutter/material/showDatePicker.html
- Usable documentation for Navigator 2.0 - I think the updated docs on navigation have addressed this issue largely.
- Debugger visibility into Dart async tasks - You can 100% debug async tasks.
- Stop HTTP requests on timeout - This exists in Flutter https://stackoverflow.com/a/51489701
- Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
- UI inspection tools that don't randomly stop working - Never had this happen.
Just an additional note: Integration testing was indeed completely broken for a while, with the docs stating otherwise. They reworked it a few releases ago and since then it works well for us (limited usage, but completely stable for what we do with it).
Do you have tests that run on your host machine, can start an API server and interact with it, and also drive the Flutter app? Or do your tests run on the mobile device?
The tests run on the mobile device, or rather mostly the emulator. No API server to interact with (and I would not know why?). The shop uses integration tests for three things: 1. Testing some migrations 2. Click through the app, as part of a release checklist 3. Run crypto operation to check multiple plugins for continued compatibility.
Integration testing supports only running tests inside the device. If your test needs to start an API server, then you must use the deprecated and broken flutter_driver module. See the bug I linked.
Flutter's Cupertino dark mode support is broken. Some text is invisible. Some widgets are unusable. Cupertino Dark mode theme support is completely absent. See the bug I filed, with a comprehensive reproduction with screenshots. It's like the dev who added it just decided to stop half-way.
> - iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
Please use an iOS device and notice how nicely one can dismiss the keyboard in iMessage, FB Messenger, Instagram, etc. Getting that behavior in Flutter requires using a third-party package.
The Material date picker is not a date-time picker. Letting the user pick a date & time requires a lot of extra code. For example, I spent many hours writing a widget that displays the date & time and lets one click to change it, like in Google Calendar.
See the bugs I linked about Navigator. The docs have multiple omissions. I lost a day and a half on them.
Yes, you can debug tasks with a breakpoint. You cannot see which async tasks are running. You cannot pause a task. I needed to debug concurrent RPC problems and tried using print. Unfortunately, print provides no visibility into tasks running in standard library code, like timed-out HTTP requests that continue running.
You can timeout waiting for an HTTP request to finish, but the request still continues in the background. If it's a large upload then it can continue for minutes, draining the device's battery and transferring data. See the bug I linked.
> - Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
How do you install on iOS? I tried `flutter build --flavor staging --release` and then `flutter install` which fails saying that I must supply `--flavor`. But when I supply `--flavor` it says the parameter is not supported. See the bug I linked. I spent a few hours and figured out how to first do a Flutter build and then use XCode to build again, then use Devices & Simulators to manually install the archive. But this requires that I remove the app from the device first, which destroys the app state. This makes manual testing extra slow. The process is noxious.
Flutter Inspector in Android Studio on macOS breaks 1 out of 5 times I try to use it. I often waste a few minutes trying to figure out why my code changes did not have the desired change on the widget tree. Then I finally realize that the widget tree pane is broken and I need to restart Android Studio. It's been like this since 2018 through multiple upgrades of Flutter, Android Studio, and macOS.
Flutter's Cupertino dark mode support is broken. Some text is invisible. Some widgets are unusable. Cupertino Dark mode theme support is completely absent. See the bug I filed, with a comprehensive reproduction with screenshots. It's like the dev who added it just decided to stop half-way.
> - iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
Please use an iOS device and notice how nicely one can dismiss the keyboard in iMessage, FB Messenger, Instagram, etc. Getting that behavior in Flutter requires using a third-party package.
The Material date picker is not a date-time picker. Letting the user pick a date & time requires a lot of extra code. For example, I spent many hours writing a widget that displays the date & time and lets one click to change it, like in Google Calendar.
See the bugs I linked about Navigator. The docs have multiple omissions. I lost a day and a half on them.
Yes, you can debug tasks with a breakpoint. You cannot see which async tasks are running. You cannot pause a task. I needed to debug concurrent RPC problems and tried using print. Unfortunately, print provides no visibility into tasks running in standard library code, like timed-out HTTP requests that continue running.
You can timeout waiting for an HTTP request to finish, but the request still continues in the background. If it's a large upload then it can continue for minutes, draining the device's battery and transferring data. See the bug I linked.
> - Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
How do you install on iOS? I tried `flutter build --flavor staging --release` and then `flutter install` which fails saying that I must supply `--flavor`. But when I supply `--flavor` it says the parameter is not supported. See the bug I linked. I spent a few hours and figured out how to first do a Flutter build and then use XCode to build again, then use Devices & Simulators to manually install the archive. But this requires that I remove the app from the device first, which destroys the app state. This makes manual testing extra slow. The process is noxious.
Flutter Inspector in Android Studio on macOS breaks 1 out of 5 times I try to use it. I often waste a few minutes trying to figure out why my code changes did not have the desired change on the widget tree. Then I finally realize that the widget tree pane is broken and I need to restart Android Studio. It's been like this since 2018 through multiple upgrades of Flutter, Android Studio, and macOS.
so much this
[deleted](1)
How not to get what you want
The only way I will get what I need from Flutter Team is if Sundar fixes the company's incentive structure to align employee incentives with long-term profitability. I do not expect that will happen. But if it did, I would probably immediately go back to work at Google and buy Google stock.
scrame(3)
I actively avoid apps built on Flutter - they don't feel or act like a native app.
I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages.
Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't really enjoy using it.
The only reason to use Dart is Flutter, which really hurts ecosystem health / library availability and prevents code sharing with the backend.