I'm actually a great fan of flutter and imo it is the best cross-platform solution out there. Probably except for web: though it produces very good result performance-wise, the end result is never really "web" and doesn't act like traditional web. As for desktop applications(whether it be windows, linux or mac), it seems like it's too mobile-oriented. I see great potential for simple solutions like self-service operations where you need a basic UI and it would be great if it could easily target platforms like raspberry pi (arm processors running Linux). But at the moment, while possible, it is a very painful thing to tackle and I wouldn't rely on something like that for an end product. I would assume that this is why google is working on fuchsia but way too few devices are supported. And neither of them is cheap(which is what could be a game changer, going back to the raspberry pi).
I've been using Flutter in the last few months and agree. It's the best multi-platform solution for mobile, although it still doesn't match native behavior and performance, it only gets close.
On the web it's DOA for most use cases - it's just a canvas, so scrolling, text selection, shadow rendering, etc. is custom, doesn't feel native and must be downloaded and compiled.
It can have a future on desktop. One "cultural" obstacle is that the de facto default widget system is Material, which is simply a wrong approach to desktop UI.
Flutter's ability to "compile to web" was something that confused me at first as well, but on second thought it's genius. It makes it easier to ease managers into selecting Flutter since deployments and updates are done via a web browser. If that works for them then maybe there's never a need to go fully native though that option exists if they want to -- and the ability to go back to compiling for web gives managers a sense of "this isn't a one-way, I'm screwed if something goes wrong" journey.
Dart actually has a lot of characteristics that make it appealing for a lot of the areas I'd have (begrudgingly) used Go - command-line tools or local utilities. It "can" be scripted, but also AOT compiles, has a saneish type system with generics, and doesn't have pointers to deal with. It's hard for me to want to use it on the web, but I keep watching it and wishing good things for it.
My experience with Flutter was that making the UI itself was pretty great. But making the rest of the app sucked. FFI support is bad. Platform channels are miserable. Doing it all in Dart is awful because there's no cheap concurrency - it's the same multi-heap with expensive "IPC" shittiness that you get with webworkers, but way less justified since you're nearly always on platforms with native threads. It's a huge pain to try and migrate piecemeal too, so if you have an existing app/codebase you're looking at a re-write.
UI performance was fine (not any better than native though), but RAM usage was pretty bad, a lot higher than native.
What I found ironical with flutter was, besides everything being a 'widget' in flutter it doesn't actually support creation of android widgets or iOS widgets[1].
And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.
Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).
So, this makes Flutter apps available through Canonical's Snap store... which is Ubuntu-mostly right now, and controversial enough that the top item on the HN front page as I write is about an Ubuntu derivative (Linux Mint) explicitly dropping support for it. https://news.ycombinator.com/item?id=23771847
Flutter announced support for Linux. Canonical announced that they'll help the Flutter team in making Flutter a great option to do app dev on Linux. They also published Flutter SDK to the Snap store, the preferred app store for Canonical. None of this means that people cannot package and publish Flutter to Debian, Ark or Fedora repositories. It'll still support Linux as a whole as long as the dependencies are present on the system. Canoncal is just investing resources in making sure it works for their distribution of Linux as well as possible, not to ensure that it only works on Ubuntu.
The snap store support is a small part of what is announced here. The team developed a GTK+ based host for flutter, which works regardless of the packaging method you use.
The end of the blog post talks about modifications to the snapcraft build tool to fully support flutter.
My first thought when seeing this post links to snapstore was "ugh, not that garbage again". Every time I tried using Snappy on fedora it did not work and was so horrible I reverted to immediately removing snappy from my computer afterwards.
Canonical makes garbage software that is superficially easy to use but flimsy and flaky.
Having used Flutter extensively since I was first introduced to it 9 months ago, I can say that it is an absolute joy to use and build interfaces with. An easier way to install the Flutter SDK on linux is only good news and I hope it gets more developers to adopt it.
Agree, Flutter is top notch. I've had trouble pitching it as a technical solution, though. For one, I think word is out that Google will kill projects mercilessly, and there's an odd dynamic between the promotion Flutter and Kotlin/AndroidX. Generally, Kotlin comes out on top as the "safer" choice.
It's a shame, though, because the primary advantage I see with Flutter is its superior UI framework. It's leagues better than the AndroidX compatibility lasagna, in terms of architecture and DX. So it really stands out as a cross platform solution not just across iOS and Android, but especially across the Android ecosystem itself.
Google needs to release desktop apps in Flutter (Youtube Music, Chat, Meet etc..). a Webapp is fine for occasional use, but Google Chat can't compete with Slack without a real app.
I am so excited about flutter ecosystem. Hopefully linux gets first class beautiful native apps now. I also hope against hope that qt is officially supported as a backend so KDE is not left out.
Flutter implements a bespoke renderer called Skia. It is its own backend. For Qt to be compatible with Flutter you'd have to port Qt to Dart. There's nothing wrong with running Flutter apps and Qt apps simulatenously.
It would be an interesting project for someone to create a KDE type of desktop environment in Flutter. Can it be done?
Judging by the example in TFA, we must have very different conceptions of what "beautiful" means. That is an atrocious application.
* Ungodly amounts of whitespace (seriously, look at that sidebar, look at that search bar. WHY? too much optimisation for what "looks good on a screenshot", maybe?)
* Undecipherable symbols where there's plenty of f#cking space to write labels god damn it
* I bet bad/nonexistant keyboard support (remember alt-* to navigate menus?)
> I also hope against hope that qt is officially supported as a backend so KDE is not left out.
Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.
The future of cross platform desktop development looks bright. Microsoft is coming up with .NET 6 and Google has flutter. I just hope that these frameworks can replace bulky electron apps.
The "Next" and "Next + 1" versions of React Native are starting to look quite exciting too. The Microsoft-backed full C++/WinRT rewrite of the Windows desktop support seems to be making good progress. With the Office team supposedly backing React Native as their preferred cross-platform toolkit moving forward, Microsoft looks like they'll be investing in RN for the long haul.
It seems good for everybody that Microsoft seems to be putting so much work into cross-platform dev in both .NET 6 and RN.
I'm looking forward to the first stable version of Blazor, and a way to combine it with proper native mobile bindings to device APIs. Currently working on a version combined with CapacitorJS and I am in love with the possibilities.
I have a request for all the Flutter folks/fans - it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base.
I started my career writing single threaded Palm OS apps (64k limit) - there was like 10 possible widgets with 5 possible events on each widget and rest of it was application code. Mobile app development is a different beast now. Yes, I sound like old-man-yelling-at-cloud. Is this table-stakes for all UI and App development?
> it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base.
The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions.
The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.
I have [self-diagnosed] Code Style OCD. Like you, the Flutter nesting levels was a major fear entering the space. It feels both ugly and inelegant.
I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too.
Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think.
If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.
From the screenshots and gifs over there I can tell that someone is again forcing people to look at
1) animations
2) grey fonts instead of black
and they are even bragging about it being beautiful.
These also tend to enormously waste screen space.
Are especially those two things configurable by user? I mean - there has to be no animations at all (why does anyone insist on animating theme change? that is just ridiculous), and black text, not grey. If not, that is complete deal breaker. Please tell me I'm wrong and one can configure everything there.
Single word: accessibility.
More words: normal accessibility without needing to re-set whole system to be "accessible" just because one app developer can't behave.
Non-animated changed are offensive to me. Humans are built to track moving things, not a thing instantly disappearing at one point and another, similar looking thing instantly appearing at another place, with no context telling you whether it's actually the same object. This gets worse the larger the state change is.
Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.
From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.
Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.
I'm excited to have another contender on multi platform apps space but in the case of Flutter for desktop I just wonder about the RAM consumption compared to Electron.
Dart compiles to native machine code, so unlike Electron doesn't need to host an interpreter, which tends to aggressively allocate memory. Should be much friendlier on RAM.
Great news for sure. There's a React Native application that I am maintaining; it's not too complex but I would love to give a rewrite a try with Flutter and see how it does on Ubuntu.
For my usage, Flutter is a no-go for web development for the same reason as Qt: it's just a canvas, so text selection, accessibility, etc doesn't work nicely or at all.
Having recently chosen a Qt stack for cross-platform desktop development over Electron, I'm happy to see that Flutter is now a real contender in this space.
I'm curious about Flutter and Dart bindings and calling interfaces for other languages. If you can integrate a Flutter front end with a back end language of your choice, that would change a lot of things for the better. The only reactive UI offerings for cross-platform desktop development with multiple language bindings are QML, which is great, or Electron with React, which is not so great if you want to use anything but JavaScript for your back end.
> Canonical is making it very easy for application developers to publish their apps for Linux users via the Snap Store, the app store for Linux.
Ugh. No, Canonical, no matter how much you'd like it to be, the Snap Store is not, and will never be, "the app store for Linux". The last thing the Linux community wants or needs is a closed-source[0], walled-garden approach to distributing applications.
[0] For the pedants out there: yes, you can create Snaps with open tools, but the only Snap server implementation is closed.
Good to see. I've been wanting to use Flutter for a Linux-based appliance but it still needed a lot of work on that front until recently. If there was a bittorrent library in Dart as well I'd be off to the races.
Up until this time I've been using Kivy for the application, but it has a ton of issues and doesn't seem to receive much investment or support, even if you wave money around.
It's worth noting that Ubuntu support and Snap support are orthogonal. The Flutter work here generates standard ELF binaries that can be distributed outside of Snap, and Canonical's contributions to create a high-quality desktop embedder for Linux are applicable across all distros.
I'm still excited because when Canonical backtracks on Snap in a few years (like they seem to always do when trying to push some homegrown aspect of Linux), their Flutter work will still be there and will have seen years of improvements.
[+] [-] axegon_|5 years ago|reply
[+] [-] RivieraKid|5 years ago|reply
On the web it's DOA for most use cases - it's just a canvas, so scrolling, text selection, shadow rendering, etc. is custom, doesn't feel native and must be downloaded and compiled.
It can have a future on desktop. One "cultural" obstacle is that the de facto default widget system is Material, which is simply a wrong approach to desktop UI.
[+] [-] mikece|5 years ago|reply
[+] [-] blandflakes|5 years ago|reply
[+] [-] kllrnohj|5 years ago|reply
UI performance was fine (not any better than native though), but RAM usage was pretty bad, a lot higher than native.
Really fantastic iteration workflow, though.
[+] [-] Abishek_Muthian|5 years ago|reply
And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.
Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).
[1]https://github.com/flutter/flutter/issues/26134
[+] [-] biolurker1|5 years ago|reply
[+] [-] rst|5 years ago|reply
[+] [-] owaislone|5 years ago|reply
[+] [-] galgalesh|5 years ago|reply
The end of the blog post talks about modifications to the snapcraft build tool to fully support flutter.
[+] [-] canada_dry|5 years ago|reply
[+] [-] simosx|5 years ago|reply
See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype
[+] [-] topspin|5 years ago|reply
Correction: it's "the app store for Linux".
/s
[+] [-] Rapzid|5 years ago|reply
[+] [-] jaekash|5 years ago|reply
Canonical makes garbage software that is superficially easy to use but flimsy and flaky.
[+] [-] armytricks|5 years ago|reply
[+] [-] programmarchy|5 years ago|reply
It's a shame, though, because the primary advantage I see with Flutter is its superior UI framework. It's leagues better than the AndroidX compatibility lasagna, in terms of architecture and DX. So it really stands out as a cross platform solution not just across iOS and Android, but especially across the Android ecosystem itself.
[+] [-] awill|5 years ago|reply
[+] [-] eklavya|5 years ago|reply
[+] [-] zelly|5 years ago|reply
It would be an interesting project for someone to create a KDE type of desktop environment in Flutter. Can it be done?
[+] [-] andrepd|5 years ago|reply
* Ungodly amounts of whitespace (seriously, look at that sidebar, look at that search bar. WHY? too much optimisation for what "looks good on a screenshot", maybe?)
* Undecipherable symbols where there's plenty of f#cking space to write labels god damn it
* I bet bad/nonexistant keyboard support (remember alt-* to navigate menus?)
* Ugly to look at (subjective)
[+] [-] solarkraft|5 years ago|reply
Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.
[+] [-] me551ah|5 years ago|reply
[+] [-] k__|5 years ago|reply
I wish they had more funding, tho. I find Reason/OCaml more compelling than Dart.
[+] [-] WorldMaker|5 years ago|reply
It seems good for everybody that Microsoft seems to be putting so much work into cross-platform dev in both .NET 6 and RN.
[+] [-] drannex|5 years ago|reply
.Net 6 is going to be beautiful.
[+] [-] harikb|5 years ago|reply
I started my career writing single threaded Palm OS apps (64k limit) - there was like 10 possible widgets with 5 possible events on each widget and rest of it was application code. Mobile app development is a different beast now. Yes, I sound like old-man-yelling-at-cloud. Is this table-stakes for all UI and App development?
[+] [-] heavyset_go|5 years ago|reply
The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions.
The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.
[+] [-] liquidise|5 years ago|reply
I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too.
Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think.
If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.
[+] [-] Lionga|5 years ago|reply
[+] [-] tarkin2|5 years ago|reply
I’ve seen some horribly large components that would be much better if split up.
Google should really advise this.
[+] [-] gladimdim|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] hexo|5 years ago|reply
Are especially those two things configurable by user? I mean - there has to be no animations at all (why does anyone insist on animating theme change? that is just ridiculous), and black text, not grey. If not, that is complete deal breaker. Please tell me I'm wrong and one can configure everything there.
Single word: accessibility. More words: normal accessibility without needing to re-set whole system to be "accessible" just because one app developer can't behave.
[+] [-] solarkraft|5 years ago|reply
Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.
From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.
Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.
[+] [-] avilesj|5 years ago|reply
[+] [-] programmarchy|5 years ago|reply
[+] [-] CSharpRon|5 years ago|reply
[+] [-] haolez|5 years ago|reply
[+] [-] heavyset_go|5 years ago|reply
I'm curious about Flutter and Dart bindings and calling interfaces for other languages. If you can integrate a Flutter front end with a back end language of your choice, that would change a lot of things for the better. The only reactive UI offerings for cross-platform desktop development with multiple language bindings are QML, which is great, or Electron with React, which is not so great if you want to use anything but JavaScript for your back end.
[+] [-] kelnos|5 years ago|reply
Ugh. No, Canonical, no matter how much you'd like it to be, the Snap Store is not, and will never be, "the app store for Linux". The last thing the Linux community wants or needs is a closed-source[0], walled-garden approach to distributing applications.
[0] For the pedants out there: yes, you can create Snaps with open tools, but the only Snap server implementation is closed.
[+] [-] oaiey|5 years ago|reply
[+] [-] etse|5 years ago|reply
Material is well done, except I really don't like the actual design. Cupertino looks more like iOS 7 than iOS 14 and lacks something…
[+] [-] mixmastamyk|5 years ago|reply
Up until this time I've been using Kivy for the application, but it has a ton of issues and doesn't seem to receive much investment or support, even if you wave money around.
[+] [-] olingern|5 years ago|reply
[+] [-] fungos|5 years ago|reply
Snap: nope!
Anyway, hopefully this will cause a push for flutter support on other distros that are snap free.
[+] [-] timsneath|5 years ago|reply
[+] [-] Andrex|5 years ago|reply
[+] [-] reddotX|5 years ago|reply
flutter create flutter run
done
[+] [-] Dowwie|5 years ago|reply
Is anyone considering writing flutter + rust desktop apps in linux?