Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps(omgubuntu.co.uk)
omgubuntu.co.uk
Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps
https://www.omgubuntu.co.uk/2021/03/ubuntu-building-apps-with-flutter-in-future
119 comments
> VScode is a shining example of what that can accomplish
I see this mentioned quite often here, but that's not a valid argument in favour of Electron Apps.
VSCode is the primary focus for a user when it's active - so it's fine if it takes up a significant proportion of a machine's resources. Now if a bunch of background taskbar apps, calculators and notepads start doing the same, user experience is going to go downhill very quickly.
So basically, Electron is a good choice for apps in which you spend a lot of time; and a poor choice to be a preferred platform for an OS.
I see this mentioned quite often here, but that's not a valid argument in favour of Electron Apps.
VSCode is the primary focus for a user when it's active - so it's fine if it takes up a significant proportion of a machine's resources. Now if a bunch of background taskbar apps, calculators and notepads start doing the same, user experience is going to go downhill very quickly.
So basically, Electron is a good choice for apps in which you spend a lot of time; and a poor choice to be a preferred platform for an OS.
I just bought an Onivim license cause I wanted to treat myself and they're using Revery as an Electron replacement. Not sure I understand why it is faster, but I have to say the startup time is almost instantataneous and it's really responsive on a Linux 2014 i5 4Go laptop (whereas VScode ...). So it might be a good alternative.
How is Onivim? I played aroud with it v1 but wasn't impressed enough to gamble money that they'd made breakthroughs in v2
I have only used it for one day so far. I have a hard time quitting my customized terminal vim so I haven't looked much how to configure it. The only thing I can say so far is that it's beautiful, works out of the box and it is really fast and responsive.
The impact could reduced if a single Electron runtime is shared across apps. Imagine the various HTML5 mobile phone environments, like Palm's webOS, but in a desktop setting.
Since electron is basically a headless browser, you would be opening up any app with an XSS vulnerability to any other app running in the runtime.
So it needs a isolation like firefox containers
Yes, we could have tabs to switch between different applications running on that shared runtime.
And a universal way of accessing any published application for that runtime through some kind of address bar.
And a universal way of accessing any published application for that runtime through some kind of address bar.
That's essentially what a Progressive Web App is.
> it's fine if it takes up a significant proportion of a machine's resources
I currently run 2 VScode instances and they literally total 70 MB. So no, it's not significant, on the contrary actually.
And to be fair, even if it was 700 MB, I wouldn't care. Even older machines have at least 4 GB memory.
I currently run 2 VScode instances and they literally total 70 MB. So no, it's not significant, on the contrary actually.
And to be fair, even if it was 700 MB, I wouldn't care. Even older machines have at least 4 GB memory.
I'm always puzzled by these kinds of retorts. It's wonderful that you've never experienced performance or resourcing issues with Electron apps. But just because you haven't, doesn't mean other people don't.
For the record, VSCode chugs like a MF on my Thinkpad running XFCE with 4gb of RAM. Meanwhile, Sublime Text flies
For the record, VSCode chugs like a MF on my Thinkpad running XFCE with 4gb of RAM. Meanwhile, Sublime Text flies
I'm not talking about Electron apps but about VSCode specifically. I just cannot reproduce high RAM usage with it on any machine. Slack in comparison sucks bad for example, but reports of high memory usage for VSCode sound like fakes from non-users/haters.
You’re not looking at the right processes. The real work happens in “VS Code helper” child processes which take at least 500MB total, usually more. That memory is not sitting idle either, it means your CPU is churning a lot more, and its not nice when you realize your code editor is using 20%.
I fear the day we replace everything with JavaScript. All JavaScript apps are so unbelievably slow compared to native apps with native toolkits.
At work I need to use MS Teams and holy shit it's so slow and if I'm compiling code it's barely usable on an 8 core processor. I had better performance with chat clients in 2002 on hardware that was about 1% as fast as mine today.
VS Code is also very slow, you just don't notice it as much on today's machines.
At work I need to use MS Teams and holy shit it's so slow and if I'm compiling code it's barely usable on an 8 core processor. I had better performance with chat clients in 2002 on hardware that was about 1% as fast as mine today.
VS Code is also very slow, you just don't notice it as much on today's machines.
Flutter is far more worrying IMO. The Web at least is somewhat standardized and definitely going to last long. There's also nothing intrinsically too slow about it, JS runtimes can definitely be made fast and render engines tend to improve over time, it's also likely we will move on from Electron and it's bloat-packed delivery method. Everything is easily inspect-able as shipped.
Compared to that Flutter programs are a huge black-box, completely unportable as delivered not just across platforms but also between accessibility mechanisms it seems. While practically sharing none of the advantages of traditional native toolkits. Responsiveness is dismal, web/desktop targets are basically a PoC, the language and toolkit are so large it's extremely unlikely people will bother maintaining it when Google deprecates it, even if it's 100 times more popular than now. It's just disheartening how people are still keen on developing things far too likely to end in a platform graveyard.
Compared to that Flutter programs are a huge black-box, completely unportable as delivered not just across platforms but also between accessibility mechanisms it seems. While practically sharing none of the advantages of traditional native toolkits. Responsiveness is dismal, web/desktop targets are basically a PoC, the language and toolkit are so large it's extremely unlikely people will bother maintaining it when Google deprecates it, even if it's 100 times more popular than now. It's just disheartening how people are still keen on developing things far too likely to end in a platform graveyard.
I wouldn't say that is true. For something like React Native, the apps are plenty fast as JS is just used as an expressive control layer for the heavy lifting done in native code.
I think a well maintained React Native for desktop is a really good way forward.
People don't really care about a native "look and feel" any more so long as it's pretty, consistent, and integrates into the OS. Which is why electron is popular. I think the slowness of having everything rendered by a webview is the main drawback of electron, which is solved by React Native which only needs to run JSC or V8 somewhere.
I think a well maintained React Native for desktop is a really good way forward.
People don't really care about a native "look and feel" any more so long as it's pretty, consistent, and integrates into the OS. Which is why electron is popular. I think the slowness of having everything rendered by a webview is the main drawback of electron, which is solved by React Native which only needs to run JSC or V8 somewhere.
>VS Code is also very slow, you just don't notice it as much on today's machines.
Seemed to be running great on Core 2 Duo machines of the kids learning coding at a remote village I visited recently.
Seemed to be running great on Core 2 Duo machines of the kids learning coding at a remote village I visited recently.
[deleted]
In fact, I was using VS Code on 10 year old Core 2 Duo 2GHz machine up to a year ago. Without extensions, the responsiveness was fine -- definitely not as responsive as gvim, but otherwise no complaints.
When I added extensions, it did start to feel laggy but once I turned off all extensions save one (the language server extension -- in my case, Python) it was fine again.
With my current machine (a refurbed 2014 Intel i7 Dell desktop), VS Code is pretty responsive even with extensions enabled.
When I added extensions, it did start to feel laggy but once I turned off all extensions save one (the language server extension -- in my case, Python) it was fine again.
With my current machine (a refurbed 2014 Intel i7 Dell desktop), VS Code is pretty responsive even with extensions enabled.
I don't think it's safe to generalize "x is slow and electron, y is fast and native" to mean "native is fast". Electron lowering barrier to entry also means it's used by projects who aren't going to carefully profile their app no matter what, so the same app written as a native app would also be garbage. At least some of it is "correlation not causation"
And for your chat example, when I was at IBM the Sametime chat native app couldn't even accept single line incoming text without grinding a several thousand dollar machine to a halt. Bad software is going to be bad no matter what language it's written in.
And for your chat example, when I was at IBM the Sametime chat native app couldn't even accept single line incoming text without grinding a several thousand dollar machine to a halt. Bad software is going to be bad no matter what language it's written in.
Electron lowers barriers for people who know web development already. Not generally.
Lotus apps were known for being unusually slow. Visual Studio Code is known for being unusually fast for an Electron app. And it still chokes on files Sublime Text handles easily.
Lotus apps were known for being unusually slow. Visual Studio Code is known for being unusually fast for an Electron app. And it still chokes on files Sublime Text handles easily.
"native is fast" is a statement of fact that is not open to debate. That fact is obvious to anyone who understands enough about compilers. The real question is "Are the tradeoffs between native and $portable_platform worth it?", which is generally subjective.
> VS Code is also very slow, you just don't notice it as much on today's machines.
That's plain wrong. I recently upgraded my 7 years old mid range laptop and VSCode ran just fine on it, even with the required set of extensions for my projects. I upgraded because I had other issues, but VSCode wasn't one.
That's plain wrong. I recently upgraded my 7 years old mid range laptop and VSCode ran just fine on it, even with the required set of extensions for my projects. I upgraded because I had other issues, but VSCode wasn't one.
Considering Intel's pretty poor performance improvements over the last 10 years, your 7 y/o laptop is actually pretty fast. People are still using their 2015 MacBook Pros as their main machines.
Did you try loading a 50MB CSV (or similar) into VS Code? It just seems fast but it's actually pretty slow but hidden by the raw power.
Especially anything doing code analysis or typing hints is moving at glacial speeds compared to native or Java-based editors/IDEs. You just don't notice it because you probably either never experienced it or forgot how fast it can be. Everytime I have to use VS Code instead of Visual Studio, I slow down my typing because I need to wait for VSC to show me the hints.
Did you try loading a 50MB CSV (or similar) into VS Code? It just seems fast but it's actually pretty slow but hidden by the raw power.
Especially anything doing code analysis or typing hints is moving at glacial speeds compared to native or Java-based editors/IDEs. You just don't notice it because you probably either never experienced it or forgot how fast it can be. Everytime I have to use VS Code instead of Visual Studio, I slow down my typing because I need to wait for VSC to show me the hints.
Flutter is based on Dart which compiles AOT to machine code.
Did you find that on wikileak?
I honestly don't think this is a JS problem. I don't use many js apps, but I use emacs, and it's also very slow. Most of the android apps are slow. When I'm streaming something, especially on twitch, sometimes my computer can't do anything else. And I'm on a pretty good hardware (ThinkPad X1 Carbon 7th Gen). Modern software is just slow, buggy and trash. Sure maybe gtk and qt are better, but they're pretty bad too. Software is just fundamentally bad because no one, even people who're paid to make software, cares about their quality.
If global warming doesn't end up killing us all, I hope we fundamentally change the way we approach to software in the next decades.
If global warming doesn't end up killing us all, I hope we fundamentally change the way we approach to software in the next decades.
Too much software engineering is learned on the job, and your job is usually dictated by laymen you have no control over and who may or may not give a damn about your career. You might work at a hygenic, technical garden, you might work at an Agile SCRUM feature factory that de facto prohibits re-factoring.
But University CS programs aren't the proper place for this pedagogy either, and I don't see SWE guilds popping up for a few reasons.
But University CS programs aren't the proper place for this pedagogy either, and I don't see SWE guilds popping up for a few reasons.
>At work I need to use MS Teams and holy shit it's so slow a
Try Slack on Firefox or Android. Who the hell has 40 seconds for a chat to load?!
Try Slack on Firefox or Android. Who the hell has 40 seconds for a chat to load?!
[deleted]
on chromebook with rockchip cpu and 4gb memory, handles c#, go, and dart project just fine
I didn't see it back when I was doing Qt, but writing a Qt app for every platform is hard. In theory you can have Qt apps on Android, iOs, Linux, etfc but in all fairness, it is just too much of a hassle. Big headache with toolchains, dependencies, it is just not worth it nowadays.
"Write once, run everywhere" was a nice motto for Qt and I even bought it for a while but yet again does not work in practice. Flutter, on the other hand, actually works. Sure it doesn't have all the bells and whistles of OS integrations, but it is getting there. I hate the language itself, but I can't deny that it works beautifully.
If you think about it, the Qt way of doing things was quite novel back in the days and had allot of promise, but I feel that the main thing that held it back was C++ (still no official package manager and no cool CLI tools in 2021!!). I am sad that I left Qt behind since it was an amazingly modern platform when I used it, but I am glad I don't do C++ anymore.
"Write once, run everywhere" was a nice motto for Qt and I even bought it for a while but yet again does not work in practice. Flutter, on the other hand, actually works. Sure it doesn't have all the bells and whistles of OS integrations, but it is getting there. I hate the language itself, but I can't deny that it works beautifully.
If you think about it, the Qt way of doing things was quite novel back in the days and had allot of promise, but I feel that the main thing that held it back was C++ (still no official package manager and no cool CLI tools in 2021!!). I am sad that I left Qt behind since it was an amazingly modern platform when I used it, but I am glad I don't do C++ anymore.
As a KDE fan, the recent changes to QT's licensing have me concerned. [1] Given that Flutter compiles to native code, and doesn't require shipping a V8 engine with each application like Electron, this seems like a reasonable decision for them to make.
1: https://www.qt.io/blog/qt-offering-changes-2020
1: https://www.qt.io/blog/qt-offering-changes-2020
The KDE foundation is in the mix to ensure an open source path:
http://www.olafsw.de/a-better-qt-because-of-open-source-and-...
however, https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
End of last year they did release 6.0, so it looks like they're not hiding their releases for a year. You won't get the LTS fixes, for a year though.
For me, this means I have to stay on 5.15 until 6.2( because of location module) is one year released -- summer 2022.
however, https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
End of last year they did release 6.0, so it looks like they're not hiding their releases for a year. You won't get the LTS fixes, for a year though.
For me, this means I have to stay on 5.15 until 6.2( because of location module) is one year released -- summer 2022.
You don't have to wait a year for 6.2. 6.2 will be released immediately, and also the initial bugfix releases (e.g. a future 6.2.1, or most recently 6.0.1). Only once a particular version branch is declared LTS do additional bugfix releases become commercial-only - with 6.x, that means the next feature release (and perhaps even bugfix releases for that) will most likely be already available by the time an older branch goes LTS.
Additionally, Qt changed its approach to bugfix commits to go to dev first and then get backported, so even if a distro is stuck on an older version branch in LTS mode, critical fixes will be available publically and can likely be backported manually.
Overall the change to the LTS support strategy isn't amazing, but it's impactful mainly to 5.15.x since it's LTS and the transition to Qt 6 will take some time. Once the transition is over I suspect it won't be a significant issue however.
Additionally, Qt changed its approach to bugfix commits to go to dev first and then get backported, so even if a distro is stuck on an older version branch in LTS mode, critical fixes will be available publically and can likely be backported manually.
Overall the change to the LTS support strategy isn't amazing, but it's impactful mainly to 5.15.x since it's LTS and the transition to Qt 6 will take some time. Once the transition is over I suspect it won't be a significant issue however.
Fantastic! I really want Qt 6 because of the QML compiling and even the ability to nuke the javascript engine, if possible. I want to try out the low end targeting as well.
So, if you report a bug in 6.2, then you'll get the bug fixes in 6.3, assuming the fix got into the dev trunk before the end of the 6.3 release window?
So, if you report a bug in 6.2, then you'll get the bug fixes in 6.3, assuming the fix got into the dev trunk before the end of the 6.3 release window?
Yes. But you may also get the fix in 6.2.1 and 6.2.2 and who knows how many - until 6.2 is declared LTS (and only if that happens), then those 6.2.x releases become commercial-only from that point on.
IMO they are bidding on Flutter hoping that it'll become next big thing replacing Android. It'll allow for easy porting mobile apps to Linux.
Time will tell whether they're right or not. They made some failed bids in the past (Mir, upstart), but at least they're trying to move.
Time will tell whether they're right or not. They made some failed bids in the past (Mir, upstart), but at least they're trying to move.
Could be. Maybe they learnt from Ubuntu Mobile, where they wanted app developers to write QT apps, instead of having support for e.g. apk files (the payoff for the time invested in writing a separate app for Ubuntu phones was never going to be there, unfortunately).
I think it's a positive that they're moving to a more common platform that is easier for developers to produce a build for. Good luck to them.
I think it's a positive that they're moving to a more common platform that is easier for developers to produce a build for. Good luck to them.
> They made some failed bids in the past (Mir, upstart)
Bzr, Launchpad, Unity, Juju, etc. They have a ton of misses.
Bzr, Launchpad, Unity, Juju, etc. They have a ton of misses.
>VScode is a shining example of what that can accomplish.
A platform should be evaluated by what an average team can make with it, not by one shining example -- because a sufficiently talented team can make something excellent on any platform.
If the VSCode team had built something like VSCode on another platform, I'd probably like it even better than I like VSCode.
A platform should be evaluated by what an average team can make with it, not by one shining example -- because a sufficiently talented team can make something excellent on any platform.
If the VSCode team had built something like VSCode on another platform, I'd probably like it even better than I like VSCode.
Qt is going commercial only. GTK+ feels kinda old when working on it and GTK team likes to break compatibility. Flutter is also quite bad often, dependency hell on big projects is so much hotter than anything I've ever seen on npm. Flutter is smooth, maturing fast, developing in Dart is simply pleasant.
Qt is not going commercial only
I stopped reading at "snap" ...
[deleted]
I am bringing some negative energy but I've been burned.
I don't understand the hype about flutter - putting aside that dart is a tool that made more sense in a different timeline, or that some of the examples seem really slow/buggy, or that it's rendering behavior is a nightmare to guarantee consistency - putting all that aside, I've yet to see anyone build anything non-trivial with flutter.
And then there's Ubuntu. Canonical is just all over the place. There was Unity, there was their weird mobile phone, there was their mobile OS, the weird ads in desktop searches. I am doubtful anytime I see anything Ubuntu related.
I don't understand the hype about flutter - putting aside that dart is a tool that made more sense in a different timeline, or that some of the examples seem really slow/buggy, or that it's rendering behavior is a nightmare to guarantee consistency - putting all that aside, I've yet to see anyone build anything non-trivial with flutter.
And then there's Ubuntu. Canonical is just all over the place. There was Unity, there was their weird mobile phone, there was their mobile OS, the weird ads in desktop searches. I am doubtful anytime I see anything Ubuntu related.
> Canonical is just all over the place.
We should encourage experimentation and risk taking. No company can always get things right.
Phones are a duopoly, but I'm glad they tried. Unity was fairly decent, but in the end adopting Gnome benefitted everyone. Ads were the only bad idea I can think of; but hey I've been using their wonderful software for 15 years now at a total cost of zero.
We should encourage experimentation and risk taking. No company can always get things right.
Phones are a duopoly, but I'm glad they tried. Unity was fairly decent, but in the end adopting Gnome benefitted everyone. Ads were the only bad idea I can think of; but hey I've been using their wonderful software for 15 years now at a total cost of zero.
In theory I agree, but Canonical really seem to do it over and over. Whether it's NIH or something else, it seems every time technology starts shifting, Ubuntu goes its own way only to drop it a year or two later. Unity/compiz, Mir , Ubuntu One, Upstart, Bazaar. And currently baking are Snaps and LXD. This isn't to say any of these are bad products, but it has real effects to the end user, who invest time in something that just seems to get vaporized.
Don't forget that snaps came almost a year before flatpak. This is being parroted all over HN and still many don't know it and blame Canonical for reinventing the wheel, which is why I'm posting this.
(I agree with your general idea and the rest of your comment.)
https://en.wikipedia.org/wiki/Snap_(package_manager)
https://en.wikipedia.org/wiki/Flatpak
(I agree with your general idea and the rest of your comment.)
https://en.wikipedia.org/wiki/Snap_(package_manager)
https://en.wikipedia.org/wiki/Flatpak
Don't forget that FlatPak has been designed out in the open and plans were presented as far back as GUADEC 2013.
https://www.superlectures.com/guadec2013/sandboxed-applicati...
https://www.superlectures.com/guadec2013/sandboxed-applicati...
What is wrong with LXD? It provides a nice REST API and better user experience for those of us who like LXC.
Bazaar and snaps came before git and flatpak.
Unity came about with the Gnome 2 to 3 transition (and earlier versions of Gnome 3 were widely agreed to be a step backwards).
Upstart has a very different design philosophy than systemd. Hard to say its NIH when it was different tech.
NIH apparently means "not adopting whatever RedHat develops/supports".
Unity came about with the Gnome 2 to 3 transition (and earlier versions of Gnome 3 were widely agreed to be a step backwards).
Upstart has a very different design philosophy than systemd. Hard to say its NIH when it was different tech.
NIH apparently means "not adopting whatever RedHat develops/supports".
Bzr and Git started at about the same time, but Git moved much faster and its 1.0 was way before bzr(not that that matters much, honestly).
Flatpak was known about and talked about before snaps, as another pointed out.
Upstart - that's fair, upstart was something new that didn't get replaced by systemd for a couple cycles.
Like it or not, Red Hat controls gnome which is a huge ecosystem. Your best bet for effecting change there is collaboration, not hacking together your own UI for yourself. I mean, sure they are free to do that, but the writing was on the wall before it even started.
Flatpak was known about and talked about before snaps, as another pointed out.
Upstart - that's fair, upstart was something new that didn't get replaced by systemd for a couple cycles.
Like it or not, Red Hat controls gnome which is a huge ecosystem. Your best bet for effecting change there is collaboration, not hacking together your own UI for yourself. I mean, sure they are free to do that, but the writing was on the wall before it even started.
There was literally nothing wrong with Canonical technology. They just kept cancelling projects to satisfy a vocal minority of Ubuntu users.
No, we didn't. Unity was cancelled when we downsized in 2017 (4 years ago). It wasn't due to any vocal minority at all. We just refocused our energy.
Flutter deserves the hype it's getting. I've been developing apps for 20 years, it's the real deal. We're using it at our company to rebuild our app and now have a single front-end codebase which compiles to web, iOS, Android, Windows, Linux and macOS.
You can try the demo here: https://demo.invoiceninja.com
You can try the demo here: https://demo.invoiceninja.com
FYI this is what it looks like on my iPhone
https://imgur.com/gallery/A5ltUKC
Thanks for trying it out!
It looks like you tried refreshing the data in the app to resolve the problem, does refreshing page in the browser help?
Not sure why I'm not seeing the same problem on my iPhone. If you use the app and would like me to help debug it feel free to email us at [email protected].
It looks like you tried refreshing the data in the app to resolve the problem, does refreshing page in the browser help?
Not sure why I'm not seeing the same problem on my iPhone. If you use the app and would like me to help debug it feel free to email us at [email protected].
Scrolling is not the smoothest, and that’s on the latest iPhone, but overall pretty good. I can see it working if it becomes as responsive as web / native.
Thanks for trying it out!
I'll be the first to admin that the performance is currently not quite as good as a plain HTML/JS/CSS webapp, however as a small team being able to compile one codebase to every platform is game changing.
The performance issues of Flutter Web are more apparent on mobile however users can install our native mobile app which performs much betters.
I'll be the first to admin that the performance is currently not quite as good as a plain HTML/JS/CSS webapp, however as a small team being able to compile one codebase to every platform is game changing.
The performance issues of Flutter Web are more apparent on mobile however users can install our native mobile app which performs much betters.
Yes, in my view Canonical betting on flutter is almost a testament to flutter doom. Choosing flutter is not the right choice anyway: it’s a lot more limited compared to Qt, it requires a language which is not used anywhere else, it’s slow and heavy, its tooling is incredibly complex, on some platforms won’t probably be ported anytime soon (if ever).
what exactly of flutters tooling is complex ?
getting through the tutorial is a 15min thing. I don't see much complexity exposed to the developer.
getting through the tutorial is a 15min thing. I don't see much complexity exposed to the developer.
> After all, people have been predicting that web-based tech will be the next big thing on desktop for as long as I’ve been writing this blog — i.e. eons. And yet it never quite happens. Electron apps, for instance, are, like Flutter, popular with web devs but desktop users? Well, they’re less keen.
Lost me here. I don't think most users care whether their apps run Electron or .NET or Python/QT or whatever so long as the app works. Stigma as a dev makes me want to avoid Electron apps but that's because I'm a dev.
If the point is about desktop apps vs. apps that actually run in the browser (e.g. Sketch vs. Figma) then that's a real debate. But that has nothing to do with Electron.
Lost me here. I don't think most users care whether their apps run Electron or .NET or Python/QT or whatever so long as the app works. Stigma as a dev makes me want to avoid Electron apps but that's because I'm a dev.
If the point is about desktop apps vs. apps that actually run in the browser (e.g. Sketch vs. Figma) then that's a real debate. But that has nothing to do with Electron.
Electron apps use more CPU and drain the battery faster on my Linux laptop. Users may not care what framework renders their apps, but if they were running more than one or two electron instances they may start to notice their battery life is awful. It’s worse on Linux already, there’s no reason to make it even worse.
Faster than? Do you compare applications that do similar things?
Other text editors. Other chat apps. Other music players. The same apps before Electron.
Take a look at desktop Telegram when you have some time. It bundles its own fork of Qt (which inflates its shared memory usage as nobody else is using the library), has a very polished UI and all the same features as any other modern messenger, and runs circles around any Electron application I've ever seen. On my machine from 2014 it starts instantly and the memory usage never goes above 200-250 MBs, which is not ideal, but still is ~4 times less than the _startup_ memory usage of an Electron application.
Thanks for the numbers, thats indeed quite a difference.
I just started VSCode on my desktop. Its "_startup_ memory", with something like two dozen extensions installed, is sitting at 170MB. I also just started Discord on my desktop. Its "_startup_ memory" is 39MB.
Now Slack's a pig at 380MB, fresh-opened, sure. But reality doesn't really seem to oblige these kinds of claims in 2021.
Now Slack's a pig at 380MB, fresh-opened, sure. But reality doesn't really seem to oblige these kinds of claims in 2021.
Are you looking at a single worker process out of about 10? This is such a frequent mistake it's not even funny. Do something resembling a proper measurement: run `free -m` (or the alternative on your OS) before starting VSCode, and then right after it finishes loading, ideally on a completely bare system to reduce noise.
Here are my numbers for a freshly installed 1.53.2 with zero plugins and no configuration:
Here are my numbers for a freshly installed 1.53.2 with zero plugins and no configuration:
used
2882
used
3404
I'm on Windows at the moment and, yes, I'm looking at the whole application's memory usage. Even with half a dozen tabs open, right now, it's sitting at 250MB combined. (Which--well, I've got 64GB, I shall benevolently allow it.)
Discord has jumped up to about 300MB with a bunch of use, though 50MB (?!) of that is the Discord updater, which is pretty wild.
Discord has jumped up to about 300MB with a bunch of use, though 50MB (?!) of that is the Discord updater, which is pretty wild.
I wish there was a stickied post feature to head off these sorts of RSS measuring contests.
Multiprocess applications, and especially multiprocess applications with really big discardable caches, are extremely difficult to compare apples-to-apples.
Multiprocess applications, and especially multiprocess applications with really big discardable caches, are extremely difficult to compare apples-to-apples.
I think what is meant is that while some electron apps are popular in the developer demographic (i.e. VS Code) the average desktop user does not run many of then, and is more likely to use desktop apps written in non-web technologies (VLC, Transmission, Office, and whatever it is people use these days)
As far as I know Discord, Skype, and Slack are all electron based. Office is mostly used online.
Electron is a really easy way to add Linux support to your app.
Electron is a really easy way to add Linux support to your app.
[deleted]
Slack, Spotify, Signal and Whatsapp desktop, Skype, Discord, MS Teams are all built on web tech. I think even Office 365 nowadays has a lot of the UI stuff written in react native.
A lot of older linux software is non-web based but that's not the average desktop user.
A lot of older linux software is non-web based but that's not the average desktop user.
> I think even Office 365 nowadays has a lot of the UI stuff written in react native.
Where can I read about this?
Where can I read about this?
I think I read about this on twitter from one of the webpack devs a few years ago, might have been this chain. (https://twitter.com/TheLarkInn/status/1006746626617008128)
I think for react native in windows apps more generally the github page is a good start
https://github.com/Microsoft/react-native-windows
I think for react native in windows apps more generally the github page is a good start
https://github.com/Microsoft/react-native-windows
Yes. I use VS Code and it works really well for me. The fact that it’s an Electron app is of no concern to me.
RStudio is also web-based tech — which enables it to run in a browser when remotely hosted.
And these are some of the most widely used IDEs out there (IDEs are also a class of desktop apps that have an above average UI complexity). I don’t think a majority of users are “less keen” just because they’re web based tech.
Maybe the only nitpick I would have is the odd web debug menu that would pop up on occasion when one right clicks on certain UI widgets.
RStudio is also web-based tech — which enables it to run in a browser when remotely hosted.
And these are some of the most widely used IDEs out there (IDEs are also a class of desktop apps that have an above average UI complexity). I don’t think a majority of users are “less keen” just because they’re web based tech.
Maybe the only nitpick I would have is the odd web debug menu that would pop up on occasion when one right clicks on certain UI widgets.
[deleted]
[deleted]
As both a Flutter dev and an Ubuntu user, I am thrilled by the news. Looking forward to seeing how it all works out.
In a nutshell, if anyone is interested how this works, the Flutter apps will be converted and compiled as GTK3 apps. Dart has the FFI package so it's fairly simple as a Flutter dev to do C system calls in Dart. This will of course stop your app from being cross platform out of the box (but I doubt this is a concern for the Ubuntu team).
In a nutshell, if anyone is interested how this works, the Flutter apps will be converted and compiled as GTK3 apps. Dart has the FFI package so it's fairly simple as a Flutter dev to do C system calls in Dart. This will of course stop your app from being cross platform out of the box (but I doubt this is a concern for the Ubuntu team).
> converted and compiled as GTK3 apps
What do you mean by that? Isn't one of the goals of Flutter that it gives you pixel-perfect controls, and renders everything itself?
What do you mean by that? Isn't one of the goals of Flutter that it gives you pixel-perfect controls, and renders everything itself?
I assume parent means that the compiled flutter app uses GTK3 as the shell for spawning windows and initializing the Skia context to which the app can render.
This is also how Druid the Rust GUI framework works on Linux. Use GTK to start the window and the paint surface (Cairo).
This is also how Druid the Rust GUI framework works on Linux. Use GTK to start the window and the paint surface (Cairo).
Time for me to move away from Ubuntu, then. This and apt randomly installing snaps isn’t what I want. I’ll give Arch a shot, it’s been the new hotness for a long time...
Debian is great and will be very familiar coming from Ubuntu. The next stable release is coming in June too.
Debian is closer than Arch FWIW, though of course Arch is good too.
This is very very sad news, but consistent with the slippery slope that Canonical is following in the recent years.
They look like to not care about users anymore, as with snaps, but behave like any other business of the silicon valley without real value.
Flutter does not even make sense with desktop apps. It is like electron mediocre apps.
What I see here is Canonical following whatever they can get from the biggest players like a hooker, to try to get attention.
They look like to not care about users anymore, as with snaps, but behave like any other business of the silicon valley without real value.
Flutter does not even make sense with desktop apps. It is like electron mediocre apps.
What I see here is Canonical following whatever they can get from the biggest players like a hooker, to try to get attention.
Okay, a few things here.
Canonical are a UK-based company, nothing to do with the Silicon Valley.
Flutter compiles to native code and uses Qt behind the scenes. Electron uses an embedded Chrome to render stuff with web tech. How are they even remotely alike? They're cross-platform, yes, and Dart is supposed to be a better JavaScript, but that's it.
Canonical are a UK-based company, nothing to do with the Silicon Valley.
Flutter compiles to native code and uses Qt behind the scenes. Electron uses an embedded Chrome to render stuff with web tech. How are they even remotely alike? They're cross-platform, yes, and Dart is supposed to be a better JavaScript, but that's it.
As a non-UI developer (I specialize in NLP, deep learning, and knowledge graphs), I like Flutter because it is so easy to make cross platform apps that someone like me can get started quickly. I would expect that experts would still prefer native Android, iOS, desktop, etc. frameworks.
Any pointers from someone with DL/AI background in Python? I was looking to do web development with flask, postgresql,HTML/CSS... Does flutter just replace front end and interact with the flask rest api instead of things like jinja templates?
Flutter supports server side dev also.
Would React Native not be a better choice and more open? It's based on existing widely used JS technologies, it is fast, and doesn't have the drawbacks of electron, and you can easily develop for mobile as well.
There are a couple actively maintained projects for RN on desktop such as:
https://proton-native.js.org/#/
https://microsoft.github.io/react-native-windows/ (though this lacks Linux support at the moment).
There's also React NodeGUI, however I don't think people care about having native buttons etc as much (as evidenced by VSCode, Slack, etc, and the plethora of other successful Electron apps) any more.
https://react.nodegui.org/
There are a couple actively maintained projects for RN on desktop such as:
https://proton-native.js.org/#/
https://microsoft.github.io/react-native-windows/ (though this lacks Linux support at the moment).
There's also React NodeGUI, however I don't think people care about having native buttons etc as much (as evidenced by VSCode, Slack, etc, and the plethora of other successful Electron apps) any more.
https://react.nodegui.org/
Canonical already went down this route, but I'm not sure why it was abandoned: https://github.com/CanonicalLtd/react-native
I guess that makes Dart a less dead language than it used to be, but from what I can tell there’s almost no momentum around Dart at all.
Basing your future applications on a language which seemingly is already slipping into its coffin (even discounting the regular Google discontinuing thing), seems like a really weird choice.
Basing your future applications on a language which seemingly is already slipping into its coffin (even discounting the regular Google discontinuing thing), seems like a really weird choice.
Since the releases of Flutter and Fuschia, the development of Dart went tenfolds. Devs post performance improvement reports from time to time.
https://medium.com/flutter/flutter-performance-updates-in-th...
https://medium.com/flutter/flutter-performance-updates-in-20...
https://medium.com/flutter/flutter-performance-updates-in-th...
https://medium.com/flutter/flutter-performance-updates-in-20...
How many 100% Canonical applications are there in an Ubuntu install? The installer and... maybe the repository management UI? I mean, it's clearly an announcement to make Google happy and try to help giving Flutter some momentum but hardly a defining decision for Ubuntu as a desktop.
I don’t know if this will continue to be true forever. Dart is actually an awesome language to work with generally and is only continuing to get better.
I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks, even some basic things like ORMs and dependency injection frameworks are few and far between still.
I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks, even some basic things like ORMs and dependency injection frameworks are few and far between still.
> Dart is actually an awesome language to work with generally and is only continuing to get better
Not to kill your enthusiasm, but that can be said for almost any new language.
> I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks
Which is why an active and vibrant ecosystem around the language increasingly is more important than the language itself.
Just look at Go. A terribly, inexpressive language where the common solution is to write code-generators.
But it has an ecosystem and the stuff people need. So people use it to write more software and more Go-libraries, reinforcing the platform-effect.
Not to kill your enthusiasm, but that can be said for almost any new language.
> I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks
Which is why an active and vibrant ecosystem around the language increasingly is more important than the language itself.
Just look at Go. A terribly, inexpressive language where the common solution is to write code-generators.
But it has an ecosystem and the stuff people need. So people use it to write more software and more Go-libraries, reinforcing the platform-effect.
Hmm I'm not a fan of flutter at all.. It's pretty poor on mobile, you can always tell when an app uses it because it feels 'out of place' on the platform.
Though I guess it is better than Electron because that's really wasteful and bad. There's a few pearls like VS Code but 95% of Electron apps are horrible (including other MS apps like Teams, Yammer etc).
Anyway pretty much everything Ubuntu does these days rubs me the wrong way. Snap in particular (super slow to start, and only works with their own store). I still use it for work a bit because we only have 2 choices and I hate Red Hat even more :)
But my point is, Canonical keeps pushing stuff that's great for their interests (snaps with their IoT ambitions, and trying to rope other distros into their snap store) and for developers, but not for the users.
Though I guess it is better than Electron because that's really wasteful and bad. There's a few pearls like VS Code but 95% of Electron apps are horrible (including other MS apps like Teams, Yammer etc).
Anyway pretty much everything Ubuntu does these days rubs me the wrong way. Snap in particular (super slow to start, and only works with their own store). I still use it for work a bit because we only have 2 choices and I hate Red Hat even more :)
But my point is, Canonical keeps pushing stuff that's great for their interests (snaps with their IoT ambitions, and trying to rope other distros into their snap store) and for developers, but not for the users.
I tried it out the other day after seeing this announcement.
So, I created the default app and it ran fine. Then I wanted to add a menubar to the window, so I found the Flutter menubar plugin, installed it and got it working.
My first menu items were _File -> E_xit. The Alt+ keyboard acceleration indeed worked on my system (Manjaro/XFCE) without any problem! However, as soon as I wanted to handle the "Exit" action I got stuck.
I searched around a bit but I could not find an answer. How do you exit a Flutter desktop app programatically?
So, I created the default app and it ran fine. Then I wanted to add a menubar to the window, so I found the Flutter menubar plugin, installed it and got it working.
My first menu items were _File -> E_xit. The Alt+ keyboard acceleration indeed worked on my system (Manjaro/XFCE) without any problem! However, as soon as I wanted to handle the "Exit" action I got stuck.
I searched around a bit but I could not find an answer. How do you exit a Flutter desktop app programatically?
Wow, that’s a risky bet. Google may change their mind in 1 year and just drop the project, as they do so often. That’s enough for me to be sure I won’t build anything based on one of the company side project as I never know (and have no way to know) what is an experiment or an actual product they plan to maintain long term.
Hopefully for Canonical everything will go well, I wish them good luck.
Hopefully for Canonical everything will go well, I wish them good luck.
Yes! This will be interesting to say the least.
This article is just riddled with typos.
With default theme "Yaru" supported by community, Ubuntu is introducing whole new framework, that will require quite a bit of work to make it look similar to native applications.
They should stick with GTK, as GTK4 has made some really nice performance improvements and can be used with many different programming languages: C, Python, Javascript (GJS), Vala, just to name a few.
The story of UI development since the web happened.
It is like the sky falling on your head, tomorrow never comes.
It is like the sky falling on your head, tomorrow never comes.
Until the dust settles Linux Mint is a pretty good option.
Is Flatter runtime native or some kind of vm?
There's a pure-VM mode for development and an AOT compiled mode for production.
Also, their big contribution to Flutter is getting it on the snap store? Quit trying to turn Linux into a walled garden with your app store. If you are considering snaps, please consider Flatpak instead.