As someone developing GUIs with Qt bindings for Python daily, and has been for the past 8-9 years, I respectfully disagree.
Understanding of the underlying types and memory management is rarely an issue (e.g. once every 3 months), and when it is it's incredibly straightforward (e.g. maintaining reference to a window you've just created else Python garbage collects it for you).
Topics like these appear every now and then and remind me how there are still developers out there that still struggle to find the right combination of language and framework, some resorting to Electron because of assertions like this. This is a solved problem for my line of work - VFX and workflow related tools.
The styling system of qt is also quite limited. Their 'css' is a small set that does not work well on everything.
HTML+CSS allows for creating almost anything, it's the same on all platforms if the renderer is right. It's seperate from code and easily viewable and debuggable within a browser program. I have yet to see anything similiar with Qt, or a style heavy program like Discord made in Qt without becoming spaghetti.
But I also disagree that the styling is quite limited. Yeah, css in Qt is pretty limited, but creating a custom widget doesn't require all that much intimate knowledge (depending how custom we're talking). You can tweak the behavior of default widgets easily, you can draw a completely new one by painting and following the rules (for sizing, redrawing, etc). For new interaction models you'll need to be more familiar with the internals, but that's the case if you're stretching the limits of any framework.
Qt works really well for cross-platform apps that adhere to the OS' style and behavior. I think way too many apps waste time and frustrate users by reinventing the wheel. QML seems to be their approach to UIs untethered to the host OS (I don't have any experience) and seems to be their focus for the past handful of years. Their Qt (Widget) demos always show a bunch of cool features I rarely use, but I do pilfer their code for examples when I need something.
For a Discord like example; Maya, Nuke, and Houdini were all originally developed using their own UI toolkits and have migrated to Qt while maintaining each of their distinctive behaviors. They are all cross platform and require relatively low overhead and high performance with heavily customized UI behaviors.
Maya: https://damassets.autodesk.net/content/dam/autodesk/www/camp... Nuke: https://www.foundry.com/sites/default/files/styles/teaser/pu... Houdini: https://d2wvmrjymyrujw.cloudfront.net/media/uploads/products...
These apps did fork Qt5 when they moved from Qt4 to Qt5, but it was mostly Qt4 regressions and did it in a way intending to contribute their changes back into Qt mainline.
I see Electron devs being asked to match the slickness of an existing website with similar delivery time and productivity. You don't seem to be able to get close to that with native APIs, API frameworks, or higher-level tools without a lot of work. When you remove these UI and delivery requirements then almost all other frameworks seem to have a fighting chance.
From my perspective as a user, Electron apps are for companies who don’t really care much about quality and are too cheap and lazy to write native apps. YMMV.
Ironically, Microsoft was one of the early adopters of the idea of "web technologies for desktop apps":
About a year ago I began work on Label LIVE, an Electron app to interface with thermal label printers. It’s not perfect but it fills a niche. It wouldn’t exist if it wasn’t for Electron. Check out the video or download and give it a try. http://label.live
The whole reason OSes give you reusable components is so its easy to implement the conventions users are familiar with. Those are the things that are supposed to be fast and easy.
This likely violates the delivery timelines, but Maya, Nuke, and Houdini are all professional, heavily customized apps that were written in their own UI toolkits but were ported years ago to Qt and are cross platform.
Jupyter Notebook does this.
What's the reason, lack of discoverability? I'd rather run one Chrome instance than a dozen apps that use varying versions of Electron.
The dependency on Chrome is a turnoff for people who don't already use Chrome. An Electron app just depends on the operating system (apparently), so the install is much like other desktop apps.
PWA's are a sandboxed environment, where devs do not have control of browser version, cannot modify chromium, and cannot bundle necessary binary code. Even Spotify bundles in faster JSON parsers, and probably a number of other things.
An average user might not be able to connect the dots this way and realize what's going on with their machine. They'll just complain "my laptop is slow all the time and I don't know why". As developers, I feel like we have a responsibility to take better care of our users in this manner. Using a solution that will consume a GB or more of unshareable memory for something that doesn't need it (which is mostly everything) is a poor choice that puts the developer's needs (write-once-run-anywhere; faster, cheaper development time; fewer developers needed) over the user's.
So I fundamentally disagree that users only care that the app does the things they want, and nothing more.
Is this part of what Microsoft is doing with Chrome being pre-installed (via Edge)? I can't find a source, but I heard that using the existing chrome on the machine would reduce disk size for applications and possibly even allow them to share memory.
Though Qt Widgets in C++ isn't too bad if you use the designer instead of insisting on doing everything in code.
[0]: https://bitbucket.org/chromiumembedded/java-cef
[1] https://github.com/MGWL/QtE5
D's team is doing an incredible job of matching C++ compiler specific ABIs, name mangling/etc -- just so D users can use C++ libraries (including templates) directly from D without loosing the features of the language.
[2] https://dlang.org/spec/cpp_interface.html
Here is also an older video of Walter Bright (2015) talking about the challenges that D is tackling
The alternatives for cross-platform GUI are
1. Electron
2. Frameworks like C++/Qt C/Gtk
3. Bindings to (2)
Using frameworks like Qt in native C++ sucks because C and C++ are just terrible languages for GUI development, even with the bolted on object systems and language extensions (Qt extends the C++ language).
Using bindings to those frameworks is nice in theory because you don't have to manually manage your own memory or use their type system, but in practice you still need to understand how their types bridge to your language's types and how their memory management bridges with your language's memory management (typically a GC). So while you're dealing with C types and manual memory management less frequently, when you do have to deal with it, it's more complicated than dealing with it in standard C/C++. So (3) is hardly better than (2).
Electron is probably the most cost-effective option, but it has its own problems (notably the high resource consumption that comes from bundling a whole web browser).
With those considerations in mind, learning a new high level language is the least of all problems, especially if the GUI framework is high-quality.