Ask HN: Should Qt be considered in the place of electron?
When a cross platform app is required, Electron is often mentioned first: Should Qt be considered to fill that gap (As in the new QML-y Qt)
53 comments
I hear this a lot, as a contrast to Electron, but I haven't seen any examples of good cross-platform Qt apps.
The only Qt app I've used recently is VirtualBox, which is terrible on the Mac. The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
I searched the web and found that Google Earth Pro also uses Qt, so I downloaded that. It looks awful, too. The scrollbars, split panes, buttons, and toolbars look wrong. Checkboxes are drawn mangled, animation is absent, and the outline view doesn't size its rows correctly so the bottom half of text is cut off. Despite language being "System default" in the Earth prefs, and English being the top language in my System Prefs, part of the UI is in Japanese (my #2). The view right after launch: https://i.imgur.com/eDvSoUm.png
I think a good first step would be looking at existing Qt apps. Are you OK with the quality of apps like VirtualBox and Earth? Alternatively, do you think you can do a better job at this than Google and Oracle?
I think if you're planning to write a typical Qt app, in order to make 'native app' fans happy, you're going to be in for a surprise.
The only Qt app I've used recently is VirtualBox, which is terrible on the Mac. The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
I searched the web and found that Google Earth Pro also uses Qt, so I downloaded that. It looks awful, too. The scrollbars, split panes, buttons, and toolbars look wrong. Checkboxes are drawn mangled, animation is absent, and the outline view doesn't size its rows correctly so the bottom half of text is cut off. Despite language being "System default" in the Earth prefs, and English being the top language in my System Prefs, part of the UI is in Japanese (my #2). The view right after launch: https://i.imgur.com/eDvSoUm.png
I think a good first step would be looking at existing Qt apps. Are you OK with the quality of apps like VirtualBox and Earth? Alternatively, do you think you can do a better job at this than Google and Oracle?
I think if you're planning to write a typical Qt app, in order to make 'native app' fans happy, you're going to be in for a surprise.
> The only Qt app I've used recently is VirtualBox, which is terrible on the Mac. The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
On Windows and Linux (primarily Ubuntu), KeePassXC, VirtualBox and VLC have been pretty good in my experience and they're Qt as far as I know. Dropbox uses Qt as well, however, it's interface is minimal. Electron doesn't even try to look or behave natively for what it's worth.
On Windows and Linux (primarily Ubuntu), KeePassXC, VirtualBox and VLC have been pretty good in my experience and they're Qt as far as I know. Dropbox uses Qt as well, however, it's interface is minimal. Electron doesn't even try to look or behave natively for what it's worth.
Curious. VLC on MacOS doesn't exhibit any of the weird UI glitches that other Qt apps have, and an inspection of the package shows it doesn't contain any Qt frameworks.
VLC's Wiki [1] says: "Qt / Qt4 is the default, plain, graphical, interface to VLC, made using the Qt library (Linux users may need to have this installed). It is used as the default interface on the Windows and Linux versions of VLC media player from version 0.9.0 and above."
[1]: https://wiki.videolan.org/Qt_Interface/
I googled for "dropbox mac qt" and only found this page [2] from 2014 which says they were experimenting with rewriting the Dropbox UI in Qt for Linux and Windows. The linked post [3] says the Qt rewrite is for Windows and Linux only.
[2]: http://www.webupd8.org/2014/07/dropbox-ui-rewritten-in-qt-fo... [3]: https://web.archive.org/web/20141015093406/https://forums.dr...
I consider Qt (along with Gtk+) to be native on Linux -- there's no more-native toolkit that it's wrapping or emulating.
So I find it interesting that these cross-platform applications (Wikipedia lists 9 platforms for VLC!) both use Qt for only 2 platforms, and 1 of those is where it's native, anyway. These are mature applications which have clearly put a lot of effort into both user experience and cross platform support, and they have already gone to the trouble of implementing their UI in Qt, but for most platforms they choose not to use it.
What I get from this is: Qt is useful as a cross-platform GUI toolkit only for targeting Windows. Is that overly cynical?
VLC's Wiki [1] says: "Qt / Qt4 is the default, plain, graphical, interface to VLC, made using the Qt library (Linux users may need to have this installed). It is used as the default interface on the Windows and Linux versions of VLC media player from version 0.9.0 and above."
[1]: https://wiki.videolan.org/Qt_Interface/
I googled for "dropbox mac qt" and only found this page [2] from 2014 which says they were experimenting with rewriting the Dropbox UI in Qt for Linux and Windows. The linked post [3] says the Qt rewrite is for Windows and Linux only.
[2]: http://www.webupd8.org/2014/07/dropbox-ui-rewritten-in-qt-fo... [3]: https://web.archive.org/web/20141015093406/https://forums.dr...
I consider Qt (along with Gtk+) to be native on Linux -- there's no more-native toolkit that it's wrapping or emulating.
So I find it interesting that these cross-platform applications (Wikipedia lists 9 platforms for VLC!) both use Qt for only 2 platforms, and 1 of those is where it's native, anyway. These are mature applications which have clearly put a lot of effort into both user experience and cross platform support, and they have already gone to the trouble of implementing their UI in Qt, but for most platforms they choose not to use it.
What I get from this is: Qt is useful as a cross-platform GUI toolkit only for targeting Windows. Is that overly cynical?
It's interesting that it seems Qt is not used to target Macs. Perhaps Qt really is only good for cross-platform development on Windows and Linux.
> The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
And how native do the controls on electron apps look? IME these apps always look completely alien and won't use the native controls with the native theme. I see this criticism frequently and it seems like people hold Qt to a higher standard than electron and then dismiss it because it doesn't meet that higher standard.
And how native do the controls on electron apps look? IME these apps always look completely alien and won't use the native controls with the native theme. I see this criticism frequently and it seems like people hold Qt to a higher standard than electron and then dismiss it because it doesn't meet that higher standard.
> And how native do the controls on electron apps look?
Completely custom -- but at least they're not chopping off the bottom 2/3 of a line of text.
I hate Electron as much as anyone, but I really don't understand how being able to read all the text in a user interface could be considered an unreasonably high standard for a software program.
Completely custom -- but at least they're not chopping off the bottom 2/3 of a line of text.
I hate Electron as much as anyone, but I really don't understand how being able to read all the text in a user interface could be considered an unreasonably high standard for a software program.
A single and likely application specific bug doesn't demonstrate much. Having the wrong language for that entry is likely a google earth problem, not a qt one, the text cutoff could be a number of things, like the developers manually setting max height, in which case you'd see similar results of the did the same in electron/css, gtk or just about anything else.
Technically true -- which is why my original question was: is there any example of a good cross-platform Qt app?
Of the examples I've seen posted, half have exactly the same weird UI bugs, and the other half turned out to not be Qt at all.
I'll grant that it is possible that Qt is perfectly fine at cross-platform GUIs on all of its supported platforms, and all these poor examples can be explained by (a) these particular developers simply did a poor job, (b) they all failed in the same way (maybe there's a flag to make all Qt controls look and act non-native, which they set by accident?), and coincidentally also (c) everyone writing good cross-platform apps happens to limit their use of Qt to just Windows and Linux, for completely unrelated reasons. I'm of course skeptical, but I grant this is all possible.
Even if so, I maintain that it's still an unnecessary engineering risk to use a tool for a task where you've never before seen it used well and successfully.
Besides, I disagree that bugs like drawing checkboxes wrong (until you resize the window) are "likely an application specific bug". I've never seen any other GUI toolkit mess up drawing checkboxes. That's just fundamental. I don't even know how I could screw that up using any other toolkit.
Of the examples I've seen posted, half have exactly the same weird UI bugs, and the other half turned out to not be Qt at all.
I'll grant that it is possible that Qt is perfectly fine at cross-platform GUIs on all of its supported platforms, and all these poor examples can be explained by (a) these particular developers simply did a poor job, (b) they all failed in the same way (maybe there's a flag to make all Qt controls look and act non-native, which they set by accident?), and coincidentally also (c) everyone writing good cross-platform apps happens to limit their use of Qt to just Windows and Linux, for completely unrelated reasons. I'm of course skeptical, but I grant this is all possible.
Even if so, I maintain that it's still an unnecessary engineering risk to use a tool for a task where you've never before seen it used well and successfully.
Besides, I disagree that bugs like drawing checkboxes wrong (until you resize the window) are "likely an application specific bug". I've never seen any other GUI toolkit mess up drawing checkboxes. That's just fundamental. I don't even know how I could screw that up using any other toolkit.
> Alternatively, do you think you can do a better job at this than Google and Oracle?
Not sure what this "appeal to authority" is supposed to mean. I've seen -- and worked on -- many high-quality Qt applications. Granted, I'm not a Mac user, but on Windows and Linux they can look just as good as any other "native" applications.
"I think a good first step would be looking at existing Electron apps. Are you OK with the quality of apps like the Slack client and Microsoft Teams? Alternatively, do you think you can do a better job at this than Slack and Microsoft?"
Not sure what this "appeal to authority" is supposed to mean. I've seen -- and worked on -- many high-quality Qt applications. Granted, I'm not a Mac user, but on Windows and Linux they can look just as good as any other "native" applications.
"I think a good first step would be looking at existing Electron apps. Are you OK with the quality of apps like the Slack client and Microsoft Teams? Alternatively, do you think you can do a better job at this than Slack and Microsoft?"
I shipped a commercial app on Qt in the early 00s. The Mac port just never nailed the finer UI details to the same standard as Qt/Windows and Qt/Linux. Qt's customers ended up being the embedded market and phone vendors, I don't think their Mac port was ever adequately resourced.
I'm happy Qt/Mac exists, it made our Mac port commercially viable, and a couple days of polishing work would make the UI "good enough". If we'd done continuous deployment it would have been annoying.
I'm happy Qt/Mac exists, it made our Mac port commercially viable, and a couple days of polishing work would make the UI "good enough". If we'd done continuous deployment it would have been annoying.
Do you hold Electron apps to the same bar? Do they resemble Mac apps?
Electron apps look and act oddly, in a different way, and no, I don't have any installed. I only have one Qt app (VirtualBox) installed, because it's the only free virtualization system I know of. I only use it via Vagrant, so I never have to see it.
The only Qt app I use on macOS is Viber, it looks pretty bad and non native.
Heck yes.
I still don't get how so many creators of apps justify choosing Electron to themselves, what with all the downsides (resource usage, power consumption, accessibility, security, and so on).
Another GUI-framework I've enjoyed using is wxWidgets, which provides a thin abstraction to a platform's native widgets. Has a bunch of language bindings, and a pretty liberal license as well.
Another GUI-framework I've enjoyed using is wxWidgets, which provides a thin abstraction to a platform's native widgets. Has a bunch of language bindings, and a pretty liberal license as well.
I've used an editor and two IDE's that are built off wxWidgets. They are all fast and responsive. And support Windows, Mac and Linux. As in they 'work' for all three.
I think wxWidgets supports a variety of bindings for different languages as well.
Never used it but C#/netcore might be a good choice as well. I've only used C# with winforms though, so the danger I'm talking out my ass is high.
I think wxWidgets supports a variety of bindings for different languages as well.
Never used it but C#/netcore might be a good choice as well. I've only used C# with winforms though, so the danger I'm talking out my ass is high.
What exactly is the security concern by using Electron?
Accessibility is only achieved by the creator's intention.
Accessibility is only achieved by the creator's intention.
Well, it brings the usual web security issues to the desktop, dragging with it much of the browsers' attack surface.
Also, there's been a bunch of CVE – there's one [0] in particular that springs to mind.
[0]: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...
Accessibility is only achieved by the creator's intention.[0]: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...
I did an app on wxWidgets a few years ago. It's really kinda good - a lot like what MFC should've been.
As much as I enjoy working with Qt, I wouldn't bet on it for the future. QML support still seems a bit iffy and being told QWidgets are being phased out is disheartening. The framework is in a sort of limbo stage where newcomers don't really know how to proceed. The lack of popularity (outside of some niches) doesn't help either.
I hate working with web frameworks but the network effect is real and not in favor of Qt. Perhaps there was a time when Qt was thriving and innovating, but right now it seems like it's just a bunch of fortune 500 companies paying 1-2 Qt developers to maintain legacy software.
Sometimes I wonder if there is an alternate universe where Qt won "the battle" and made the world a better place. Sadly for us, that didn't happen here.
I hate working with web frameworks but the network effect is real and not in favor of Qt. Perhaps there was a time when Qt was thriving and innovating, but right now it seems like it's just a bunch of fortune 500 companies paying 1-2 Qt developers to maintain legacy software.
Sometimes I wonder if there is an alternate universe where Qt won "the battle" and made the world a better place. Sadly for us, that didn't happen here.
I believe "old school" Qt has a number of professional niches that wouldn't dream of using anything else. Certainly visual effects software is Qt heavy.
QWidgets are being phased out? What???
No, they are just mostly finished and aren't seeing a lot of new feature work being done ,if any. Qml is a way better way so that's what they are working on. It gets better every release, and that guy doesn't have a clue. Sorry. Just for the record, QML is awesome.
> they are just mostly finished
Yeah, I don't know how much experience you have with Qt but widgets are far from being "finished". There's plenty of things that could be improved if their focus wasn't on Qt Quick.
The use of Qt Widgets is declining (albeit slowly), as stated in http://blog.qt.io/blog/2019/01/14/qt-customer-survey-2018/. You're telling me that they're going to support two different technologies that do the same thing without giving preference to the newer, technically superior one?
Qt Quick is intended to replace Qt Widgets, but it isn't currently at a stage where that's feasible -- hence my apprehension.
Yeah, I don't know how much experience you have with Qt but widgets are far from being "finished". There's plenty of things that could be improved if their focus wasn't on Qt Quick.
The use of Qt Widgets is declining (albeit slowly), as stated in http://blog.qt.io/blog/2019/01/14/qt-customer-survey-2018/. You're telling me that they're going to support two different technologies that do the same thing without giving preference to the newer, technically superior one?
Qt Quick is intended to replace Qt Widgets, but it isn't currently at a stage where that's feasible -- hence my apprehension.
Yeah, that's not true. They have said that Qt4 widgets are feature finished, and not being deprecated. Obviously eventually there will be little use of the older way, but they have repeatedly said they are not deprecating them. Believe what you want.
I'm aware that they aren't being deprecated, but that doesn't mean they aren't being phased out. When I say it is being "phased-out" I'm referring to how it will no longer be advertised as the optimal solution to a problem. Perhaps we're just arguing semantics at this point?
You can use the tool until it's deprecated. Everything is constantly being "phased out".
Phasing out is the same as sunsetting, i.e., terminating: https://whatis.techtarget.com/definition/sunsetting
From the first post, I assumed the commenter meant something like, "in Qt 6 QWidgets will stop working", which is insane.
From the first post, I assumed the commenter meant something like, "in Qt 6 QWidgets will stop working", which is insane.
I guess it was poor wording on my part then, sorry. I only meant that it was not going to be the focus of the product anymore.
Data_Junkie(1)
Actually, this is funny because that's literally what I have been doing for the last 2 startups I co-founded.
The first one was in 2013, so Electron was not an option at the time, I needed a runtime to run my webapp (in the healthcare industry, for many legal reasons and budget, I could not and would not have it hosted on the internet, so I needed it to be a desktop app). At the time it was webkit, and it already was a great experience. The app was part C++, part Angular1, all the data was stored locally in a sqlite db. The company is still running, and the app is on the verge of being rewritten (basically because the new CTO is not much into C++) with Electron.
Second project, started in 2016, originally a React Native app (IOS and android), but many customers wanted a desktop/web version. Web was a lot of work because the app depends on storing data locally (sqlite again), so to make it fast, I did a first prototype with Electron, spent a week on but I had many issues with building native nodejs modules, so I dropped it and back again on Qt, but today it's all chromium-based instead of webkit. So I wrote the native part I needed in C++ (was fast and easy because the Qt library covers a lot), bridged it to the application, and the port of the ReactNative app was completed in less than 2 months.
I like Electron very much, but if you know C++, Qt is great competitor as a webengine runtime. Of course, I had my share of issues with Qt, but I don't feel like it would have been really better with Electron, whatever the framework, there are always issues.
The first one was in 2013, so Electron was not an option at the time, I needed a runtime to run my webapp (in the healthcare industry, for many legal reasons and budget, I could not and would not have it hosted on the internet, so I needed it to be a desktop app). At the time it was webkit, and it already was a great experience. The app was part C++, part Angular1, all the data was stored locally in a sqlite db. The company is still running, and the app is on the verge of being rewritten (basically because the new CTO is not much into C++) with Electron.
Second project, started in 2016, originally a React Native app (IOS and android), but many customers wanted a desktop/web version. Web was a lot of work because the app depends on storing data locally (sqlite again), so to make it fast, I did a first prototype with Electron, spent a week on but I had many issues with building native nodejs modules, so I dropped it and back again on Qt, but today it's all chromium-based instead of webkit. So I wrote the native part I needed in C++ (was fast and easy because the Qt library covers a lot), bridged it to the application, and the port of the ReactNative app was completed in less than 2 months.
I like Electron very much, but if you know C++, Qt is great competitor as a webengine runtime. Of course, I had my share of issues with Qt, but I don't feel like it would have been really better with Electron, whatever the framework, there are always issues.
Qt with or without QML should definitely be considered. Granted, I can't say I've ever made more than a toy application in Qt (via Python and PySide).
A third option if you're too afraid of C++ or one of the Qt bindings, and you really need something web-like, is JavaFX.
A third option if you're too afraid of C++ or one of the Qt bindings, and you really need something web-like, is JavaFX.
I'm developing something on Electron, but casting occasional glances at Qt wondering if it'd be better.
It's hard to beat the edit-test-debug cycle of Electron, where I can tweak a line of code, hit Cmd-R, and see the results in less than a second.
It's hard to beat the edit-test-debug cycle of Electron, where I can tweak a line of code, hit Cmd-R, and see the results in less than a second.
QML is just as fast. If you don't make any changes to the C++ side of things then there's no recompiling needed.
Does anyone have experience with Proton Native? https://proton-native.js.org/#/
Never used it myself but I wonder if it is a more performant alternative to Electron
Never used it myself but I wonder if it is a more performant alternative to Electron
Does anyone else find Qt difficult to setup/compile and find the qtmoc hoops that are necessary really frustrating when it comes to compiling projects in a non standard way?
Has anyone tried react-native-desktop that uses QT? What are your experiences?
https://github.com/status-im/react-native-desktop
https://github.com/status-im/react-native-desktop
Of course. If it's only for desktops, you should go with Qt Widgets.
Well, if I can ditch chromium, I'm all for it.
Will look into it.
Another option is SWT and the Eclipse RCP.
Also consider Adobe AIR.
Can Qt run in a browser?
There's your answer.
There's your answer.
Yes, it does: http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/
Looking at the widget gallery (http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...) I want to complain about what a waste the 5.6MB download is, but that's probably smaller than a lot of new sites and most android apps.
I now fear this might become viable and websites will become a black box where things like ad blockers don't work.
I now fear this might become viable and websites will become a black box where things like ad blockers don't work.
More like Qt runs the browser.