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.
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.
Python probably does eliminate a lot of problems of QT, much of its being the static typing of c++. However you are still bound by qt's internal widgets. Creating custom widgets requires reasoning about the renderer and qt's internal code.
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.
I think Python is a poor choice for UI because it doesn't have a history of handling asynchronous things well. It leans on Qt a lot.
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.
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.
Putting aside the many resource problems with Electron apps, can you achieve the level of user experience that the Electron folks do?
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.
My experience is that every Electron app I’ve ever tried has a terrible “user experience” compared to average competently made native Mac apps. Their core UI widgets are non-standard for the platform and are full of bugs and inconsistencies. Latency is through the roof on all sorts of common interactions. They don’t integrate well with standard expected OS features/services. They burn massive amounts of system resources.
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.
I’m a company of one and I care about quality. I’ve shipped native apps for Mac, iOS and Android.
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
My argument is that the UI requirements are almost always nonsense. I hate launching a new app and trying to figure out a new interaction model or fighting a themes/fonts that fight my needs (font sizes, contrasting colors, etc). Basic stuff is often broken and there's a long tail, if ever, for them to get fixed. They're also the best candidates to break during an OS or other library update.
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.
FreePascal with Lazarus, the true cross-platform GUI framework is similar to Delphi's VCL or .Net's WinForms, it's been in active development for over a decade, and you compile your program into native machine code to a lot of platforms.
Why is Electron so popular, but PWAs have seemingly failed to take off? Everyone was beating the PWA drum for a while, but I've almost never seen it implemented.
What's the reason, lack of discoverability? I'd rather run one Chrome instance than a dozen apps that use varying versions of Electron.
My guess is that teaching users a different way to install a desktop app limits adoption.
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.
What matters to developers is not the same as what matters to users.
Users: Does it run and do the things I want and It's obvious how to access it?
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.
I've given up on Electron-based apps and just use the corresponding webapp in a tab in Firefox (and if they don't offer one, I usually just do without the app). I got here because I got tired of running several extra browsers that ate up my RAM and killed performance.
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.
A lot of PWA features aren't implemented everywhere, and that depends entirely on browser vendors' decisions. i.e. a lot of API's are not supported in Mobile Safari, and in general, it takes a pretty significant amount of time for a Web feature to appear in all major browsers.
Because with Electron the "app builder" decides which extensions are ran. With a PWA, the user. Like 33% of all users use ad blockers, so its all about $$$. That (no incentive), and Electron was first...
QML is in the category of "learning a new language", although last I tried it it was very much a work in progress. Can't speak to how good it is today.
QML is a declarative language; it has curly braces like JS, but that's about it. It also allows you to extend it with (some old, possibly noncompliant version of) JS, but the declarative markup is a distinct language.
That's like saying every YAML or JSON dialect is a new language. Sure, but not a full-fledged "programming language". QML is quite nice to work with, and well suited to the problem at hand.
Granted, it's not a general purpose programming language, but it has a comparable learning curve. Certainy many times steeper than YAML or JSON or other markup languages.
To add to this, if you like concept/portability/cost-effectiveness of Electron but don't want to mess with the Node/npm ecosystem, there are chromium embedded frameworks out there for Java and Python[0][1][2].
Another alternative, I think is D-language bindings to QT (or betterC which is a subset of D allowes to use D with C runtime library, while retaining D-s class system, templates and memory safety).
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.
Embarcadero Delphi Community Edition lets you compile to Android, iOS, macOS, and Windows with it's FireMonkey framework using a single UI and single codebase. It's free for hobbyists. The paid version plus a third party component adds Linux desktop support as well.
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.