[MageSlayer]

As a Delphi/FPC/Lazarus veteran (10+ years), comparing one of the quickest compilers with Qt/Boost C++ development cycle looks like a joke. Much faster edit-compile cycle which scales without issues up 1e6+ LOC (yes, modules/incremental compilation done right right from the start)

[milcron]

The Python bindings to Qt don't require compilation. QML is an interpreted gui declaration, and Qt Quick allows programming behavior in Javascript.

[veeti]

PyQt is nasty GPLv3 or commercial license only. (And no, PySide is not an option: their last stable release is years old and for Qt 4.)

[MageSlayer]

You are not comparing apples to apples.

Try finding any native code static typing compiler with RAD on board featuring quick compilation within 2x C++ resulting binary speed.

[dkersten]

Not apples to apples, but its a pretty good tradeoff for C++ IMO: you get super high turnaround times because the bulk of the UI tweaking cycle is in QML or the RAD tools and you only need slow-compiling-C++ where native performance is required.

For me, while I like fast compile times as much as the next person, its not a deal breaker -- the workflow/environment and library features are. Ie can they easily deliver the required value to my customers. QML gives me a good middle ground between productivity & quick turnaround time, native integration and native performance. If you're unwilling to make that tradeoff, well... then you're limiting yourself to the tools that don't make that tradeoff (which may be perfectly fine, of course).

[bigtunacan]

It's not a good trade off for the end user. As it's not native you end up with a much slower running application with more memory overhead and bloat. Lazarus is compiled to small native applications that are easily installable for the user, fast, with both small memory and disk space usage.

I say this next piece as both a developer and an end user; developers of desktop applications are getting out of hand with how they treat these things. We are now to the point where a large segment of the developer population has so little regard for the end user that they believe bloatware Electron solutions are a good choice for "native" text based chat application.

[dkersten]

EDIT: reading your reply to sibling comment, I think I probably misinterpreted what you are referring to here so my below response maybe is replying to the wrong thing.

Regarding your first paragraph, Qt/QML performance is very, very good, memory use isn't insane (in my personal experience at least), rendering is solid 60fps and animations are ultra smooth. Maybe Lazarus is better, but not being a good tradeoff for the user, at least in Qt's case, just isn't true.

Regarding your second paragraph, I completely agree, it those are C++ developers using frameworks like Qt doing that. They're primarily web developers who are using what they're familiar with (JavaScript) to develop desktop applications. An Electron application is very different from a Qt application.

Even with QML, which uses JavaScript, the bulk of the Qt framework is written in C++, the declarative QML is compiled to a scene graph on load, the rendering is done in OpenGL and shaders, and any heavy lifting or performance sensitive code can be done in C++ (Qt makes it VERY easy to call C++ from JS and JS from C++). Typically only non-performance-sensitive glue logic is in JS. This is very different front Electron and Qt (even with QML) is still primarily a C++ framework.

[jcelerier]

> As it's not native you end up with a much slower running application with more memory overhead and bloat.

For Qt that's just not true: you can reach 1080p / 60fps fluid animated UI on small embedded boards such as raspberry pi's. All the rendering is done using a nifty OpenGL pipeline.

[bigtunacan]

To clarify, I was referring to the language choices here. Comparing Lazarus as opposed to Python in the particular case, as well as referring to even worse performance on Electron/NodeJS.

I certainly was not intending to imply that Qt is not performant as it certainly is. Qt is the default UI for Lazarus applications as well, but it does support other UI toolkits (such as Tk) out of the box.