Back 5+ years ago Qt was my go-to framework for cross platform GUIs. You would get the kitchen sink, but the abstractions provided were quite sane. Signals and slots, nice OpenGL and painting libraries, reasonable asthetic and layout options with snappy performance.
A while ago I entered a hackathon visualization challenge using Qt painter for rendering. I expected C++ and Qt would slow me down but the rendering speed and expansive drawing primitives were valuable! They greatly reduced my iteration time and increased fun.
Today I never create new frontend projects with Qt. I may use Qt creator with cmake for backend components, but the frontend is HTML and JavaScript with libraries like React, Three.js, D3, and bootstrap. The experience is still cross platform, but also one step away from launching as an internal portal. Distribution this way is much easier, but the tools are so flexible you need more diligence to keep the code maintainable over larger teams.
I struggle to see where you would prefer Qt for frontend code if you don't need a native app.
> I struggle to see where you would prefer Qt for frontend code if you don't need a native app.
How about actual native UIs instead of ugly, non-intuitive, slow and massive Electron apps?
I say this being a dev who works with both Qt and Electron on a daily basis. Electron has its place - but its place isn't good desktop and mobile apps. Qt is much better suited there.
Electron is only well suited if your team is extremely familiar with web dev but nothing else and you have no ability to hire a good desktop team or you need to interact with a web-only frontend library.
Just about everything in Qt is preferable - native look and feel, proper layouts, high performance rendering, small distribution size. I struggle to think of any way in which Electron is better except for perhaps library support these days.
Yeah, and it's called Hacker News - beyond that no one really cares, and uses Qt.
This might sound like a troll, but the bubble effect on HN really is that strong. The community sometimes has a strong tunnel vision and doesn't realize how it's constrained by what's on the HN front page.
Except for the millions of people using apps such as Slack or Discord or people using the new Keybase desktop offerings, or people using Atom, or VSCode.
Electron (sadly imo) is being used in plenty of newly developed cross platform applications, a lot having users that have no clue what hackernews is.
None of these apps feel quite right though. Even Atom still doesn't do DPI scaling properly. VSCode does, but opening 2 panes sometimes causes it to break.
Sample problem (left pane blurry, right pane sharp - view at 1:1 scale on ~100dpi screen to notice it easiest, but it's quite visible to me with scaling even): https://i.imgur.com/Ju0UK2K.png
I have noticed that with some Electron apps in the past, but I had actually never noticed that with Discord. I thought it was native for the first 4 months I was using it because it was just done so well, no lag and such. The one thing that usually gives away electron apps is their lack of custom right-click handling, meaning a right-click will give you the generic context menu you would normally see in a browser. Discord seems to handle all right-clicks with their own context menus which is why I never caught onto it at first.
Make the window too small and the buttons overlap in the titlebar. I didn't even pick an extremely small size or anything, this was about half my screen width on my Macbook. But this is the kind of thing that making a proper native app forces you to think about, but that making an Electron app often doesn't.
I can pretty much tell within a minute of starting an Electron app because things just don't feel right no matter what the app is. Sibling mememachine is also pretty accurate - Discord is very oversized like many other Electron apps.
Not using native platform widgets is also incredibly noticable. Every time you're not using native platform buttons or menus it's so easy to tell, it feels weirdly slow, has excessive gaudy animations, the spacing is wrong, text size is wrong, etc. That's not to say that it can't be done right just that you're on an existing platform and that consistency is key.
While you do raise some valid points, and some that I disagree with, I've grown to appreciate such apps as of late. There was a time not long ago where half the shit on my computer was Java because that was the only practical way to make a decent cross-platform application without having to relearn different things for each platform. Yeah, the whole "apps built on web-technology" movement could use some refinement to reduce bloat and such, but when done correctly, it seems to work out pretty well for the most part.
Is Electron newsworthy? Sure. At the same time there's vastly more paid Qt devs than Electron devs at this time, and more apps by orders of magnitude, including many with millions of users, and big new ones every week. Along with many application domains Electron isn't even an option in. But you wouldn't know it from HN coverage.
I use RStudio on a daily bases and it works amazingly well. VS Code has become my daily driver on Linux and Windows. I think there are plenty of good examples of electron apps and bad electron apps.
Qt is great but electron has certainly been getting better and better.
There is I think something up with your computer, or your VS Code.
I have a 4 year old mac and VS Code goes from closed to a file opened in about 4 seconds. Still a stupid amount of time for a text editor, but no-where near 30.
> Just about everything in Qt is preferable - native look and feel, proper layouts, high performance rendering, small distribution size.
While we're here, honest question: how do Electron-based apps fare in terms of accessibility (e.g. to screen readers like Orca) compared to native-based apps (GTK, Qt, MFC, Cocoa)?
As a developer I'd also prefer to use QT. I actually enjoy C++ a lot and writing performant, pleasant apps. Slow bulky electron apps are the bane of my existance but maybe they look good to an over-budget project manager.
Spotify, even with much less features and a pretty simple interface, lags out every time I load it, for 10 seconds or so, and overall isn't very responsive. Thats on a pretty good system. Winamp does everything instantly.
I see things like Electron as a form of debt in technology. You can build things cross-platform really quickly, but you're taking out a lot more debt to do it, the problem is that the app can become so popular that they never pay it back.
you don't know that the difference is due to the two platforms though
its certainly possible to make slow native apps and fast electron apps. whether yours is fast or slow, and whether you can build it quickly only depends on your skillset
>you don't know that the difference is due to the two platforms though
When loading the UI takes 4 seconds. Pretty sure thats a problem, and its impossible to actually /prove/ its 'just their code', there is supporting evidence due to the technologies they chose and the nature of why they're used.
>whether yours is fast or slow, and whether you can build it quickly only depends on your skillset
The software you are using matters a lot, too. You can't just throw any tech at a problem and it'l solve it. Your skillset is dependent upon what you know, and how you know to use it, but is limited based upon what is available and readily possible. Chromium and node.js have overhead, and are very good at some things, and other things they are much worse for than a native app. Add ontop the crazy environment of JS and its inneficiencies for performance in comparison, and you get a big pile of mud. Useful, if you need to create something quickly, like many startups.
for sure, its uncontroversial that there is overhead with JS and that when top performance is required this overhead can be too costly.
but is this the reason for a desktop music player to be lagging on a "pretty good system"? no way -- there's no real excuse for that. its just a shitty app. perhaps electron gives teams the impression they can just type npm in front of some stuff to turn their website into a performant desktop app -- not quite so ;)
> I struggle to see where you would prefer Qt for frontend code if you don't need a native app.
Specially on mobile. their decision to go with QML for mobile OS support, requiring devs to replicate native widgets, means it is a bigger effort to create multiple QML frontends, than it is to follow a MVVM architecture with as much code as possible in C++, while using native support directly, even if in different languages.
Also for those targeting mobile OSes, Xamarin has a much support for the respective OS APIs than Qt, that usually requires the extra effort of manually wrapping many of them.
As someone that prefers working on native apps to web ones, I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share.
Why are electron or web apps acceptable but Qt with e.g. a material look not acceptable?
I just don't get it. The Qt app will be faster, better looking, better integrated with OS apis much saner to develop (QML is really productive and what react would be if it could have is own DSL).
Did you miss the point I mentioned I prefer native apps?
Working on web apps is unavoidable when that is what customers are willing to pay for, on my own private devices outside work hours, pure native applications are the rules of the house.
What we really need is that fast to start up apps for customer acquisition and then the long term downloads as an offering for the customers who want the speed.
> I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share.
Well, if you do need to distribute a desktop app, the frameworks that wrap web renderers like Electron can be quite heavy. Your distribution size would almost certainly be smaller with QT.
With that said, I got into a debate a while back on HN that web technology is more expressive and miles ahead of desktop frameworks and I got buried for it. What would be nice is if someone ported ReactNative to compile to QT.
This touches on something I really want built into Synergy... a browser instances as a synergy 'client' region, so I can seamlessly share KVM into tablet devices on my desk. Then pair that up with something like TurboVNC to connect to CloudTop machines. I wonder if I could use this/QT to fake that client interaction and map the events into VNC session.
in 2014, i tried to develop a side project like this. Instead of streaming OpenGL, I chosed to turn qt into video stream. I managed to stream qt apps with OpenGL to browsers.
Similar idea as X Window client/server protocol (circa 1984). Similar drawbacks: UI experience is subject to network latency and disruptions. It also means you have to run the application on a server, in order to publish it to the web.
The "ideal" solution would be to run the entire Qt/C++ application in the browser, as a static "web page." This is can be done using WebGL and cross-compiling C++ to asm.js/WebAssembly. There are several Emscripten demos showing exactly that, with an ancient version of Qt [1]. But I guess the Qt team has decided they don't want to support that direction (i.e. not even trying to port Qt5 to Emscripten, but instead offering this "WebGL streaming" thing)? Although, given how "heavyweight" Qt5 seems to be, I guess cross-compiling the whole thing to WASM would result in something very inefficient.
Personally, I have been troubled by Qt's recent direction. First there was the confusion of legacy QWidget vs. modern QML. A modern approach to UI specification is welcome, though I question the need for embedding a JavaScript engine when QML could have been compiled to native code. But the real issue with QML is that the legacy QWidget approach was never really depreciated, so Qt was no longer a coherent, unified approach to developing UIs. Qt5 looks like two completely different UI libraries combined into a confusing whole. The general spirit seems to be that desktop applications are a second-class citizen in Qt, relegated to using legacy QWidget framework, and the new QML framework is targeted towards mobile applications (the new first-class citizen). This is unfortunate because users run most professional applications on desktops with keyboard and mouse input, not on 6-12" touchscreens. More recently, they decided that the whole "Qt Quick Controls" line had terrible performance, so they were going to dump cross-platform "native look & feel" (the original raison d'être of Qt) in favour of a "Qt Quick Controls 2 [2]. Although, more recently, they seemed to be walking back that "native look" decision (making the roadmap even more uncertain) [3]. If the message to desktop developers wasn't clear enough already, the sparse list of "Qt Quick Controls 2" [4] components that have shipped so far are squarely aimed at simple mobile apps ("Drawer," "Switch," "SwipeView," etc) and is missing basic components needed to build a desktop application (for example, no promised release date for shipping a data table view component).
It turns out that this enormous edifice that has been built up, on top of Qt's native C++ roots, is incompatible with the future direction that web browsers are taking with WebAssembly and WebGL. While these browser developments are proving to be a great thing for bringing OpenGL native applications to the web browser [5], Qt seems to be left behind. They instead have to resort to building this "WebGL streaming" functionality on top of an already teetering stack, in order to deliver applications through the web in away that has obvious drawbacks.
In my opinion, the C++ community should move past the Qt legacy and come up with a new industrial-strength, cross-platform UI library that has simultaneous first-class support for web, desktop, mobile and embedded targets.
> But I guess the Qt team has decided they don't want to support that direction (i.e. not even trying to port Qt5 to Emscripten, but instead offering this "WebGL streaming" thing)? Although, given how "heavyweight" Qt5 seems to be, I guess cross-compiling the whole thing to WASM would result in something very inefficient.
They do want to support that direction; see Lars Knoll's "Qt Project Status" talk [1] from QtConf 2016. Talk about WebAssembly starts at 50:30 and also mentions the recently-introduced QtLite as a potential path to your concern of the "heavyweight" problem.
> In my opinion, the C++ community should move past the Qt legacy and come up with a new industrial-strength, cross-platform UI library that has simultaneous first-class support for web, desktop, mobile and embedded targets.
I doubt it will ever happen.
C++ has become an infrastructure language for the lower layers of the OS and language runtimes of Apple, Google and Microsoft.
Microsoft is the only exception with UWP and C++/CX, with the alternative C++/WinRT scheduled for VS2017. Yet most of their Channel9 and BUILD GUI presentations make use of C# and VB.NET.
The only OS vendors other than Microsoft, that still offer C++ GUIs in their SDKs are the ones targeting the embedded market.
So that leaves Qt with their increasing love for JavaScript, wxWidgets or JUCE.
> In my opinion, the C++ community should move past the Qt legacy and come up with a new industrial-strength, cross-platform UI library that has simultaneous first-class support for web, desktop, mobile and embedded targets.
The "write-once-deploy-everywhere" never worked,especially across form factors and devices, I'd prefer Qt focusing on what it does best (desktop) instead of trying to be a "the least common denominator" that is broken everywhere. Each platform has its own UI/UX language, it's something one just cannot reproduce with a single framework. A Qt app feels like a Qt app, and that's fine on desktop. It's not on mobile.
A while ago I entered a hackathon visualization challenge using Qt painter for rendering. I expected C++ and Qt would slow me down but the rendering speed and expansive drawing primitives were valuable! They greatly reduced my iteration time and increased fun.
Today I never create new frontend projects with Qt. I may use Qt creator with cmake for backend components, but the frontend is HTML and JavaScript with libraries like React, Three.js, D3, and bootstrap. The experience is still cross platform, but also one step away from launching as an internal portal. Distribution this way is much easier, but the tools are so flexible you need more diligence to keep the code maintainable over larger teams.
I struggle to see where you would prefer Qt for frontend code if you don't need a native app.