> But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications
Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.
I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.
However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.
In the context of what you wrote in the article:
> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.
I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?
> I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.
I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.
However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.
In the context of what you wrote in the article:
> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.
I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?