3 ms·

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and nati

by tombert 9mo ago

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and native platform to write GUI apps? Presumably that could abstract away which bullshit Microsoft framework they came out with this week. I haven't touched desktop application programming in a very long time and I have no desire to ever do so again after trying to learn raw GTK a million years ago, so I'm admittedly kind of speaking out of my ass here.

rubymamis 9mo ago
I built my Block Editor (Notion-style) in Qt C++ and QML[1]. [1] https://get-notes.com https://get-notes.com
rjh29 9mo ago
Qt is still pretty good, but it's dated in comparison to newer frameworks like Flutter and React Native. No hot reloading of changes, manual widget management vs. React where you just re-define the whole UI every frame and it handles changes magically, no single source of truth for state, etc.
- rubymamis 9mo ago
  That's false, see QML hot reload[1]. [1] https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-reload https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-...
  - rjh29 9mo ago
    That's a third party paid addon. Hardly a fair comparison.
LtdJorge 9mo ago
And GTK4 is even very usable from Rust too. It’s not a bad development experience, but these companies probably find 100 webdevs for every system programmer.
- varjag 9mo ago
  Come on GUI apps are not systems programming, what's with this title inflation.
  - LtdJorge 9mo ago
    I didn't want to call it backend, because it's not that. Maybe desktop programmer? Anyway, if you're doing GUI in Rust or similar, you're at least handling memory and syscalls, which is closer to systems programming, I'd say.
nine_k 9mo ago
Qt means C++. I'll take Typescript over C++ for a GUI task any day. Qt is also pretty memory-hungry; maybe rich declarative (QML) skinnable adaptable UIs with full a11y support, etc just require some RAM no matter what. And it also looks a wee bit "non-native" to purists, except on Windows, where the art of uniform native look is lost. Also, if you ever plan extensions / plugin support, you already basically have it built-in. Yes, a Qt-based program may be wonderfully responsive. But an Electron-based app can be wonderfully responsive, too. And both can feel sluggish, even on great hardware. It all depends on a right architecture, on not doing any (not even "guaranteed fast") I/O in the GUI thread, mostly. This takes a bit of skill and, most importantly, consideration; both are in short supply, as usual. The biggest problem with Electron apps is their size. Tauri, which relies on the system-provided web view component, is the reasonable way.
- FooBarWidget 9mo ago
  I don't get this HN worship of Qt. Have you ever used Qt apps on macOS? They don't feel native at all. They feel sort-of native-emulating in the same way wxWidgets apps on macOS feel: they use native controls but all the little details including design language are off. I'm not saying this is a huge problem for me even if it bothers me personally. But if you're here on HN advocating native over Electron, then it seems logical to me that you would care about being truly native instead of merely "using native controls while feeling off". This is even before getting to the point that Qt isn't truly native. They just draw controls in a style that looks native, they don't actually use native controls. wxWidgets uses native controls but they don't behave better despite that.
  - rubymamis 9mo ago
    This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps. [1] https://get-notes.com/ https://get-notes.com/
    - donkeylazy456 9mo ago
ogoffart 9mo ago
Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application. That’s actually why we're working on Slint (https://slint.dev https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.
- 72deluxe 9mo ago
  How can C++ not be the "right" language? It seems to meet all the requirements for event-driven GUIs - event handlers are function callbacks after all...
  - ogoffart 9mo ago
    C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages. For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.
    - 72deluxe 9mo ago
      But desktop C++ isn't difficult or slow to write... It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe. It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases of the YouTube app or Netflix there are on iOS or Android; if speedy releases are important, it is valuing rush to production over quality, much like a processed food version of edible content. In a world that is also facing energy issues, sluggish and inefficient performance should be shunned, not welcomed? I suppose this mentality is endemic, and why we see a raft of cruddy slow software these days, where upcoming developers ("current teams") no longer value performance over ease of their job. It can only get worse if the "it's good enough" mentality persists. It's quite sad.
Anonyneko 9mo ago
One reason why I personally never bothered is the licensing of some of its important parts, which is a choice of either GPL or commercial. Which is fair, but too bothersome for some use-cases (e.g. mobile apps which are inherently GPL-unfriendly). Electron and the likes are typically MIT/BSD/etc licensed.

by tombert 9mo ago

rubymamis 9mo ago

I built my Block Editor (Notion-style) in Qt C++ and QML[1]. [1] https://get-notes.com https://get-notes.com

rjh29 9mo ago

Qt is still pretty good, but it's dated in comparison to newer frameworks like Flutter and React Native. No hot reloading of changes, manual widget management vs. React where you just re-define the whole UI every frame and it handles changes magically, no single source of truth for state, etc.

rubymamis 9mo ago
That's false, see QML hot reload[1]. [1] https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-reload https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-...
- rjh29 9mo ago
  That's a third party paid addon. Hardly a fair comparison.

LtdJorge 9mo ago

And GTK4 is even very usable from Rust too. It’s not a bad development experience, but these companies probably find 100 webdevs for every system programmer.

varjag 9mo ago
Come on GUI apps are not systems programming, what's with this title inflation.
- LtdJorge 9mo ago
  I didn't want to call it backend, because it's not that. Maybe desktop programmer? Anyway, if you're doing GUI in Rust or similar, you're at least handling memory and syscalls, which is closer to systems programming, I'd say.

nine_k 9mo ago

Qt means C++. I'll take Typescript over C++ for a GUI task any day. Qt is also pretty memory-hungry; maybe rich declarative (QML) skinnable adaptable UIs with full a11y support, etc just require some RAM no matter what. And it also looks a wee bit "non-native" to purists, except on Windows, where the art of uniform native look is lost. Also, if you ever plan extensions / plugin support, you already basically have it built-in. Yes, a Qt-based program may be wonderfully responsive. But an Electron-based app can be wonderfully responsive, too. And both can feel sluggish, even on great hardware. It all depends on a right architecture, on not doing any (not even "guaranteed fast") I/O in the GUI thread, mostly. This takes a bit of skill and, most importantly, consideration; both are in short supply, as usual. The biggest problem with Electron apps is their size. Tauri, which relies on the system-provided web view component, is the reasonable way.

FooBarWidget 9mo ago
I don't get this HN worship of Qt. Have you ever used Qt apps on macOS? They don't feel native at all. They feel sort-of native-emulating in the same way wxWidgets apps on macOS feel: they use native controls but all the little details including design language are off. I'm not saying this is a huge problem for me even if it bothers me personally. But if you're here on HN advocating native over Electron, then it seems logical to me that you would care about being truly native instead of merely "using native controls while feeling off". This is even before getting to the point that Qt isn't truly native. They just draw controls in a style that looks native, they don't actually use native controls. wxWidgets uses native controls but they don't behave better despite that.
- rubymamis 9mo ago
  This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps. [1] https://get-notes.com/ https://get-notes.com/
  - donkeylazy456 9mo ago

ogoffart 9mo ago

Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application. That’s actually why we're working on Slint (https://slint.dev https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.

72deluxe 9mo ago
How can C++ not be the "right" language? It seems to meet all the requirements for event-driven GUIs - event handlers are function callbacks after all...
- ogoffart 9mo ago
  C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages. For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.
  - 72deluxe 9mo ago
    But desktop C++ isn't difficult or slow to write... It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe. It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases of the YouTube app or Netflix there are on iOS or Android; if speedy releases are important, it is valuing rush to production over quality, much like a processed food version of edible content. In a world that is also facing energy issues, sluggish and inefficient performance should be shunned, not welcomed? I suppose this mentality is endemic, and why we see a raft of cruddy slow software these days, where upcoming developers ("current teams") no longer value performance over ease of their job. It can only get worse if the "it's good enough" mentality persists. It's quite sad.

Anonyneko 9mo ago

One reason why I personally never bothered is the licensing of some of its important parts, which is a choice of either GPL or commercial. Which is fair, but too bothersome for some use-cases (e.g. mobile apps which are inherently GPL-unfriendly). Electron and the likes are typically MIT/BSD/etc licensed.