7 ms·

I wish they would expand on what's wrong with Qt or GTK. Flutter support on both Windows and Linux is pretty bad. In my opinion, electron is a better choice f

I wish they would expand on what's wrong with Qt or GTK. Flutter support on both Windows and Linux is pretty bad. In my opinion, electron is a better choice for cross platform desktop UI--VScode is a shining example of what that can accomplish. And they're in for a lot of work if they want to customize Flutter so it doesn't look material or cupertino. 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.

jjgreen 6y ago
I stopped reading at "snap" ...
foepys 6y ago
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.
- esrauch 6y ago
  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.
  - pseudalopex 6y ago
    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.
  - epr 6y ago
    "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.
- zodiakzz 6y ago
  >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.
  - deleted 6y ago
    [deleted]
  - wenc 6y ago
    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.
- lvass 6y ago
  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.
- deleted 6y ago
  [deleted]
- CodeArtisan 6y ago
  Flutter is based on Dart which compiles AOT to machine code.
  - nsonha 6y ago
    Did you find that on wikileak?
- fizdoonk 6y ago
  on chromebook with rockchip cpu and 4gb memory, handles c#, go, and dart project just fine
- antihero 6y ago
  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.
- thiht 6y ago
  > 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.
  - foepys 6y ago
    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.
- agilob 6y ago
  >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?!
- gnulinux 6y ago
  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.
  - imbnwa 6y ago
    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.
vbezhenar 6y ago
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.
- jamesrr39 6y ago
  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.
- oblio 6y ago
  > They made some failed bids in the past (Mir, upstart) Bzr, Launchpad, Unity, Juju, etc. They have a ton of misses.
arusahni 6y ago
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 https://www.qt.io/blog/qt-offering-changes-2020
- ldiracdelta 6y ago
  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-kde/ http://www.olafsw.de/a-better-qt-because-of-open-source-and-... however, https://mail.kde.org/pipermail/kde-community/2020q2/006098.html 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.
  - sho_hn 6y ago
    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.
    - ldiracdelta 6y ago
      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?
agilob 6y ago
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.
- varajelle 6y ago
  Qt is not going commercial only
jeswin 6y ago
> 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.
- space_ghost 6y ago
  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.
  - zelon88 6y ago
    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.
    - scaladev 6y ago
      Headless? It even has the same debug console as the ordinary Chromium. Basically the only thing it misses is the URL bar and navigation buttons. It's just a browser with some OS integration slapped on the side.
      - chasd00 6y ago
        True, I’ve always thought of electron as phonegap/Cordova for desktops.
    - oshanz 6y ago
      So it needs a isolation like firefox containers
  - 6y ago
SMFloris 6y ago
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.
- skybrian 6y ago
  Are you doing cross-platform development in Flutter, or by “works” do you mean on the platform you tried?
- krzyk 6y ago
  How does e.g. Telegram does it? Isn't it QT?
deleted 6y ago
[deleted]
hollerith 6y ago
>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.

jjgreen 6y ago

I stopped reading at "snap" ...

foepys 6y ago

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.

esrauch 6y ago
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.
- pseudalopex 6y ago
  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.
- epr 6y ago
  "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.
zodiakzz 6y ago
>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.
- deleted 6y ago
  [deleted]
- wenc 6y ago
  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.
lvass 6y ago
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.
deleted 6y ago
[deleted]
CodeArtisan 6y ago
Flutter is based on Dart which compiles AOT to machine code.
- nsonha 6y ago
  Did you find that on wikileak?
fizdoonk 6y ago
on chromebook with rockchip cpu and 4gb memory, handles c#, go, and dart project just fine
antihero 6y ago
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.
thiht 6y ago
> 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.
- foepys 6y ago
  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.
agilob 6y ago
>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?!
gnulinux 6y ago
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.
- imbnwa 6y ago
  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.

vbezhenar 6y ago

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.

jamesrr39 6y ago
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.
oblio 6y ago
> They made some failed bids in the past (Mir, upstart) Bzr, Launchpad, Unity, Juju, etc. They have a ton of misses.

arusahni 6y ago

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 https://www.qt.io/blog/qt-offering-changes-2020

ldiracdelta 6y ago
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-kde/ http://www.olafsw.de/a-better-qt-because-of-open-source-and-... however, https://mail.kde.org/pipermail/kde-community/2020q2/006098.html 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.
- sho_hn 6y ago
  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.
  - ldiracdelta 6y ago
    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?

agilob 6y ago

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.

varajelle 6y ago
Qt is not going commercial only

jeswin 6y ago

> 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.

space_ghost 6y ago
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.
- zelon88 6y ago
  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.
  - scaladev 6y ago
    Headless? It even has the same debug console as the ordinary Chromium. Basically the only thing it misses is the URL bar and navigation buttons. It's just a browser with some OS integration slapped on the side.
    - chasd00 6y ago
      True, I’ve always thought of electron as phonegap/Cordova for desktops.
  - oshanz 6y ago
    So it needs a isolation like firefox containers
- 6y ago

SMFloris 6y ago

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.

skybrian 6y ago
Are you doing cross-platform development in Flutter, or by “works” do you mean on the platform you tried?
krzyk 6y ago
How does e.g. Telegram does it? Isn't it QT?

deleted 6y ago

[deleted]

hollerith 6y ago

>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.