[fizzynut]

When you write your own UI, you get used to quickly + easily being able to create custom elements that do/behave exactly as you want and even iterate on those elements to get the best user experience.

Lets say I want to control pan/tilt/zoom/focus/aperture/etc of a remote camera. If I ask lets say an expert in UI framework Z to do it, it will take them 10x longer to create a very painful experience using standard elements with poor input latency, so someone actually trying to setup a camera over/under shoots everything, but it technically "ticks every box". The path to create a better experience just isn't really there and it is difficult to undo/change all the boilerplate/structure, so version 1 isn't improved for years because it took so long to create the first iteration.

[rubymamis]

Sounds like a very specific example. But I'm still unconvinced - what will make this particular UI slow using Qt? The camera view? My Qt note-taking app is faster and more responsive than native apps like Apple Notes and best-in-class Bike Outliner. Both in loading speed (4x) and resizing (with word-wrapping) of a large text file (War and Peace).

[fizzynut]

Maybe the user wants to do real time exposure/color correction, so you want to minimise the number of frames from the moment of the input to seeing the output. To do it properly the user also would want to see analysis graphs on the screen on the same frame that's being displayed? And do this for 10 cameras at once?

Maybe your definition of "fast" for a large text file is War and Peace, and mine is multiple 1/10/100 GB text files that you want to search/interact with in realtime at a keystroke level.

I've probably written 100+ completely different "very specific examples" in very different industries, because that's where you can create much better experiences.

Generally your expectations are based around what you get as standard from the library, but if you want to get a much better experience then it immediately becomes a lot more difficult.

[rubymamis]

I believe you have proved my point that you're speaking of very niche examples. Even Sublime Text won't load a 100GB instantly on a normal machine. And I consider it a very well-made app. While of course there might be apps that will load such files instantly, they are highly optimized for such a task. My point is that Qt is more than enough to replace all those Electron, and other web-based apps, while performing as good or even better than native apps.

At the end of the day, Qt can also be just a wrapper for your highly optimized engine - for example, NotepadNext[1] is using the very performant Scintilla engine while its UI is written in Qt. From my (unscientific) tests, it's even vastly faster than Sublime Text.

BTW, I'm not saying that rendering and creating your own UI is always a bad idea. Many people do it because it's fun and challenging, or to push the boundaries. That's what Vjekoslav Krajačić is doing with Disk Voyager - writing a file explorer in C from scratch[2][3]. But for many people, that's too much. I believe Qt C++ with QML is the best combo for most people, for most applications.

[1] https://github.com/dail8859/NotepadNext

[2] https://diskvoyager.com/

[3]https://www.reddit.com/r/SideProject/comments/103b9fy/disk_v...

[fizzynut]

If everything you do stays in the rails of QT you're going to be fine. But you try to do something simple like load a 2GB file and everything starts to fall to pieces, then you're going to assume the people that wrote this are super clever and that a 2GB file is too complicated, too niche, too hard of a problem, it needs to be "highly optimised", etc.

The reality is QT/whatever program/framework is doing 100 things you don't care about when loading/rendering a file. If we only care about 1 thing we can do that much better because we don't care about the 100 other things our naïve code we wrote in 5 minutes outperforms the standard element by a factor of 1,000.