Comment by emcq | Hacker News Reader

Comment by emcq | Hacker News Reader

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.

> Electron has its place

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.

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.

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've never had any issue with Discord feeling "not quite right".

You dont know what he means? They dont feel like native, they feel like web apps.

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.

What gives away electron to me is the really giant non-native UI elements. Its like everything is as bloated as the underlying system!

> really giant non-native UI elements

You act like this is a problem exclusive to Electron apps. People have been doing shit like that forever.

Sample weird behavior from Discord:

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.

http://i.imgur.com/MOaESLC.png

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.

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.

Those load times on Electron apps, though... I'm a big fan of VS Code but 30 second reload times when updating extensions are a real PITA.

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.

I have a 8 year old Dell running OpenSUSE. I counted 9 seconds to open the app. It was 6 seconds to reload after updating 5 extensions.

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

Qt has more restrictive (or expensive) licensing for proprietary usage. Electron can freely be used in proprietary projects without buying a license.

Take Winamp vs Spotify for example.

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

cf: winamp vs windows media player

>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 ;)

There are still a lot of us embedded developers that can't or won't implement a browser/JS engine on our target systems.

We're becoming more rare these days (especially in the eyes of the Qt developers), but we still exist.

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

It sounds like https://blog.qt.io/blog/2017/02/06/native-look-feel/ is trying to address your needs.

I tried Qt 5.4 and wasn't happy with the result, ended up settling on a mix of Java, C++/CX and C++ for my mobile side projects.

From your link it seems that by Qt 6, they might eventually get something that I already have with such setup today.

Also I am planning to switch to Xamarin in future side projects.

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

And maybe losing both camps in the process.

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

Who said electron or web apps are acceptable?!?

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.

Sorry. Fair point. I confused your comment with the rest of the thread.

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.

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.

In the embeded world, we're using it in cars.

Reply on news.ycombinator.com