Comment by sho_hn | Hacker News Reader

Comment by sho_hn | Hacker News Reader

Parent Full thread

I respect your comment, but I think it's a narrow look at what Qt is and what it's used for.

You mentioned "native UI SDKs" having become preferrable, but keep in mind that in many scenarios, Qt is the native UI.

On desktop Linux there isn't a lower level toolkit Qt is translating to, but also in the many embedded products Qt is used on: Car and aviation infotainment (a prominent example is Mercedes-Benz' MBUX OS, but there's literally dozens of these built on Qt and shipping), medical equipment, industrial machines (e.g. the entire HMI sector), kiosk systems, coffee makers, ... Qt is an excellent choice for these, often the only one, and the web stack is very unattractive there due to performance/hardware overhead, quality, security, etc. They're product use cases in industry, with a lot of available very high-paying jobs.

And it's worth keeping in mind that the use cases I cited above by and large pay better than making desktop software does today, unless you're an entrenched player like Autodesk (which uses Qt doe many of its apps). In the only "this pays for a decently sized staff of engineers" desktop app products that are new that I can think of, Qt is also still doing well - say, Pix4D's apps for drone mapping/photogrammetry - because they likewise solve hard problems where you don't want to deal with the web API abstraction/quality barrier and performance overhead.

My bottom line here is: Right now, and very likely ten years from now, if you are good at at Qt you're probably going to work in a very good and stable job at a solid business. I don't see this being the case for Electron developers, and I know where I'd rather be.

As for making desktop apps, if your experience is "Looking at setting up alone, With Qt you have to struggle to compile a massive library which inevitably won't work" it shouldn't be ignored and the developer experience should be improved - tooling, build system and getting modules to devs are all mentioned in this blog. However, I have to say this has never been my experience - between Qt being packaged in Linux distros and the SDK installer on other platforms it's never been hard to set up Qt for me.

> My bottom line here is: Right now, and very likely ten years from now, if you are good at at Qt you're probably going to work in a very good and stable job at a solid business. I don't see this being the case for Electron developers, and I know where I'd rather be.

What?! If you're specialising in Qt then your skills are tied to Qt and you are tied to the health of the Qt job market. Those skills are not very transferable. On the other hand, 90% of the skills needed for Electron development are web technologies which are relevant to the massive web related job market. I know where I'd rather be.

> What?! If you're specialising in Qt then your skills are tied to Qt and you are tied to the health of the Qt job market.

This isn't how it shakes out in practice, though. If you're "specializing in Qt", what you really become is a GUI systems engineer who in the course of their career will learn the fundamentals of many of the things this entails. You'll be the person that knows how the browser works and how to write it, not the person who is beholden to its crummy abstractions on top of better APIs. Case in point - the Chromium/Blink engine used by Electron was originally a Qt codebase (KHTML).

Most Qt engineers I know have a lot more fundamental, transferable knowledge than the web engineers I know.

> Those skills are not very transferable.

I think you are very wrong. Qt is just a bunch of C++ with preprocessing. Knowing C++ is a very transferable skill.

Yes, I'm fully aware of what C++ is. I'm talking about Qt skills specifically.

My point is that in Electron development, the Electron specific skills is very small part of development. Most of the skills and tools used are also widely used elsewhere in industry. This is not the case for Qt work.

Another big user of Qt for their desktop products is Tableau, since it provides the same experience across Windows and OS X.

The article itself lists portability as their most important selling point.

Yes, but - the point the blog makes is more subtle than that. If you read closely, you'll find two contrasting and complementary statements - "desktop is the root of our offering" and "we see our biggest growth in embedded".

What's going on there is that for that lucrative OEM product market I mentioned, it's a very attractive quality of Qt that their developers can test builds (of what is technical not a desktop app as it doesn't aim to integrate with the host platform) on their desktop system instead of having to remote-deploy to the embedded device or spin up an emulator for every change (cf. https://www.youtube.com/watch?v=EswaK8hTonA&t=42s). A lot of Qt's lesser competitors in the domain don't offer this to the same extent.

The other reason is that the desktop is very important as a recruitment vector for the companies that end up picking Qt partly because of the quality of the developer talent available. Not every young developer has access to a car infotainment test rig, but they have access to a desktop system; Qt needs to be on the desktop to allow you to learn it with just a desktop system. Plus open source communities like KDE that make a lot of desktop and mobile software act as a breeding ground for talented devs.

Portability is in many ways about Qt not narrowing into a specialist/niche product, many of which it outcompetes in domains where it's the best option. So it is critical, but it's critical to avoid that slippery slope that would eventually hurt the markets that keep it afloat, even if not all the platforms equally bring in the money all times. It's about generality as a feature for a healthy systems technology.

Reply on news.ycombinator.com