The traditional widget-based Qt up to 4.x was a pretty good application development framework (not just a UI framework). From that point of view, both "modern" Qt and HTML are overkill.

No, just the other way around in fact. Qt applications don't come with a starting requirement of ~300MB just for the mandatory webbrowser - before adding any of your own code.

Funny because I think HTML is overkill and QT is good enough. HTML meaning that your app runs in a browser, which generally uses much more resources than a QT app.

HTML was designed for documents, which it does adequately. But for an actual UI, you need to be able to position things easily. HTML/CSS just has all these gotchas all over the place because the defaults are just unsuitable for UI. If you work hard enough you can something working, but QLayouts are so much easier. Then after that you have to work in a language that makes every error a runtime error and doesn't even distinguish between between float and int. Which you can work around by adding another layer, namely TypeScript. All these layers just add the complexity. Qt Widgets is one of the best-designed UI APIs.

I've kind of given up on Qt, though:

- they seem to want to go in the QML direction, and if I wanted to use JS I wouldn't be using a C++ library

- their interpretation of LGPL has historically required making the entire Qt library downloadable from your website, which is inconvenient. (This may have changed with Qt 6?)

- it never looks or works quite right on macOS. In particular, text in comboboxes is just not centered vertically correctly, and it drives me nuts.

html doesn't have events that can be connected to actions.

Doesn't resize decently, doesn't respect user's settings.

And a browser is much much slower and bigger than a qt application.