I've done both and the real answer is "it depends". If performance is all that matters, the yes, it's Qt hands down. But Qt is also significantly harder to develop and maintain, especially if you want optimized application for minimal hardware.
If by that you mean it's easier to hack together some awful JS+HTML compared to hacking together a Qt application, I agree. If you want to build a maintainable, reliable and efficient solution, I don't think there is that much difference between the two. Qt has bindings to many languages, and even if you are forced to use C++ because of hardware constraints, the fact that the Qt front end API is a million times better (easier, better documented) than whatever JS frontend, offsets the language overhead.
I'm not really sure anyone could say React or Bootstrap or whatever is 'easy to use' if you are not familiar with it. Easy to get a button on the screen, maybe, but that hardly makes a user interface.
I have worked on a project where we reimplemented an HTML5... application (information omitted to protect possible secrets). We did it in a quarter of the time with IIRC a tenth of the staff from the original, according to those who did the HTML5 version. Line count was also lower. Of course not having to redo high-level design and some lower level services was a massive benefit for us, and HTML5 frameworks weren't as good at the time.
Perhaps the most important point is that while they got a skeleton up in reasonable time, things slowed down greatly from there. The HTML5 / JS code was kind of hard to understand due to callback hell, and getting smooth performance took a huge amount of work. In the Qt version, we implemented it following some best practices and performance was great right away.
Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to.
That was the question on linked article. These days HTML becomes viable even on low-end hardware, it's even standard on some appliances (i.e. home routers) and this question is very common.
"Not sure I agree that QT is harder to develop and maintain, it depends on what you are used to."
General census is that writing clean C++ (QML was still lacking the last time I used Qt, though it might have changed since then) is a bit harder than creating HTML page.
Javascript isn't exactly known for maintainability and clean code either. I'd much prefer C++ for proper applications.
0. https://ingenico.us/smart-terminals/telium-tetra/payment-ter...
https://youtu.be/hI-gYmwL9hQ?t=1m19s
However they had to use some kind of software rendering due to lack of GPU, and QML with software rendering isn't that fast either.
When I play youtube videos in my browser I'm getting about 1/3 of the view time before the battery is out compared to using mpv with youtube-dl on my laptop.
It's not just about being able to run it at all but run it efficiently. These days anything on the web feels really sluggish and I miss the days when optimisation was a priority.
Also for me, I vastly prefer writing C++ code over html and the few times recently where I had to write webpages I used libwt[1] in C++. It's almost like using QT but for html.
False analogy. The counterpart of HTML in the Qt world is QML, not C++. C++ is the counterpart of JS (or whatever backend language the web application uses).
Also consider a QT app is much harder to style and make it look good
People with HTML5 experience is much easier to find
I'm not against QT, quite the contrary, but it's a technology that has a higher entry barrier and fewer people with experience on it
If you're developing for the desktop, Qt Widgets is definitely the way to go. No, you can't (easily) style it in your own weird, custom, way. Please don't, I want it to fit in with all the other applications on my desktop.
* There still isn't a way to have any text in your custom widgets (e.g. labels on a graph) - last time I checked anyway.
* The built in text editor widgets have an anorexic API. I wrote a serial port monitoring program and to remove the first line of text from the output window I had to record the lengths of all the lines in a JavaScript array and then remove that number of characters. And it was very slow. And selection was buggy.
* The ID scope rules are weird. Honestly I never fully worked them out. It seems like every ID is accessible from anywhere - even child components can directly access IDs in their parents. You can imagine the kind of spaghetti code that leads to.