Hacker News Reader

Comment by candiddevmike | Hacker News Reader

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.

View on HN

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

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.

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.

True, I’ve always thought of electron as phonegap/Cordova for desktops.

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.

That's essentially what a Progressive Web App is.

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.

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

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.

Sublime Text has been consistently slower for me than VSCode.

That’s simply not possible unless you mangled it with a broken extension. Sublime has its own native rendered with much, much lower latency.

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.

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.

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.

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

Seemed to be running great on Core 2 Duo machines of the kids learning coding at a remote village I visited recently.

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.

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.

Flutter is based on Dart which compiles AOT to machine code.

Did you find that on wikileak?

on chromebook with rockchip cpu and 4gb memory, handles c#, go, and dart project just fine

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.

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

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.

>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?!

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.

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.

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.

Are you doing cross-platform development in Flutter, or by “works” do you mean on the platform you tried?

How does e.g. Telegram does it? Isn't it QT?

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

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.

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.

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?

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.

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.

> They made some failed bids in the past (Mir, upstart)

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.

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

Reply on news.ycombinator.com