Qt is usually touted in HN as one of the ideal alternatives to Electron for the myriad of simple / CRUD-style applications that people decide to use Electron for.

While I agree that Qt is an excellent tool in itself, and I love using it for development, it remains a fact that people wanting to use it will need to first learn a not so excellent programming language, C++ [1]. And that's a very steep entry barrier for most people, before even starting to approach the toolkit itself!

(there's also the option to write Qt apps with Python, but that comes with its own set of challenges)

[1]: I'm a C++ programmer myself, had used Qt for a bunch of years, and would like to see it used more... but I also understand that C++ must be a horribly complex language for someone who comes from Java or Typescript; and anyway IMHO C++ is the wrong tool for the job when writing a non-specialized application, without lots of data processing, or where the utmost performance is not a priority, i.e. 99% of desktop apps that get written.

>it remains a fact that people wanting to use it will need to first learn a not so excellent programming language

And to be able to develop with Electron people must first learn a not so excellent language, JavaScript.

Complexity might be a better argument but even then, with Qt's API, most of any usual implementation can be developed with their simple, consistent interfaces; largely avoiding C++'s hidden/nuanced complexity.

Yes, I like the programming interface that Qt provides a lot more than the one of standard C++ and the STL. It's just more ergonomic, more comfortable to write and read, and works great.

> And to be able to develop with Electron people must first learn a not so excellent language, JavaScript.

Statistically speaking, "most" people already know JavaScript. I don't have numbers or stats in my hand, but my feeling is that the number of devs who are working with JS in their day to day is enormous compared to those who already have a good grasp of C++ to the point of being able to consider Qt as a tool, and jumping right into developing with it.

You can kind of see this, judging by the number of new C++ apps vs. Electron apps that get announced in here.

> While I agree that Qt is an excellent tool in itself, and I love using it for development, it remains a fact that people wanting to use it will need to first learn a not so excellent programming language, C++

I won't comment about C++, but anytime I had to use QT, it was with the official Python binding. The "developer experience" was rather nice I must say.

> While I agree that Qt is an excellent tool in itself, and I love using it for development, it remains a fact that people wanting to use it will need to first learn a not so excellent programming language, C++ [1].

I'd say the opposite. C++ is alright, but some of the stuff in Qt is simply eggregious. From the nonsensical STL duplication to the absurd take on MVC, not to mention the MOC which requires special-purpose build systems, with Qt developers have to go through a lot to get to nice-looking GUIs.

I have a pet theory where nowadays the only reason developers feel compelled to go the WebView path to write desktop apps is because frameworks like Qt simply failed to pay attention to improvements in developer experience from the past decade or two. Thus developers prefer to suffer the headaches that come with the JavaScript ecosystem than having to deal with the headaches that go with Qt and the like.

QML was my first introduction into declarative and reactive GUI programming, and it was pretty great. It also came out 4 years before React brought the same paradigm to most front-end web developers.

QML spoiled me, as React in comparison is quite clunky, so I'm not really sure where your post is coming from.

> QML spoiled me, as React in comparison is quite clunky, so I'm not really sure where your post is coming from.

My post comes from my personal and professional experience developing Qt applications with C++, which unfortunately already spans over a decade.

Given you only mentioned QML, which is a relatively new addition whose adoption rate is still negligible, my guess is that you've never worked with C++ projects that use Qt's widgets.

I've used Qt bindings in other languages and the experience was pleasant for me.

Is there no way to interface to Qt from other languages? Like Rust?

I agree I really like Qt apps. They have a consistent UI and they tend to fit in fairly well into native OS environments. And indeed they are amazingly more efficient than electron apps. One of the ones I use in all OSes is QtPass.

Actually your question made me look for the language binding pages of Qt and Gtk... I was going to say that alternative language support was much better in Gtk thanks to it having a C API as opposed to Qt with a C++ API (because C is much easier to interface with from other languages)

But now that I see it, seems that Qt has a quite interesting list of language bindings!

Qt: https://wiki.qt.io/Language_Bindings

Gtk: https://www.gtk.org/docs/language-bindings/index

Note that gtk table is for the best supported and most used ones, gtk still has a dozen unlisted bindings.

There are python bindings that I’ve found quite nice. I’ve also used the C++ bindings and found them fine. C++ is complicated, but you don’t need to make your app complicated because of that.

This is why they keep pushing QML and published a free book for it: https://www.qt.io/product/qt6/qml-book

The newest Qt has become irrelevant for most companies that build embedded products. The GPLv3 got mixed in with 5.7, and all of my customers are stuck on a fork of 5.6. They will never upgrade. Given that licensing situation, I am unlikely to ever touch newer versions.

Nice to see that Qt is still going strong.

I wonder when KDE will start using Qt 6?

When Qt 6 reach feature parity (right now it is a 5 light) AND when The Qt Company stops being a dick to the community. I don't see this happening anytime soon.

Aha see, I had no idea of these things happening behind the scenes. I'm a heavy KDE user but I don't follow the development closely (though I'm always on the latest version).

Thanks for explaining!