Qt is nice. GTK is... ok. But to get a cross-platform build with either of them requires a couple of hours' fiddling around. The later you wait to go cross-platform, the more platform-specific assumptions creep into your code and the longer it'll take. But no-one wants to spend that couple of hours fiddling around right at the start of their project, when it's just a dozen lines to fix their own problem.
With electron you write that dozen line helper utility and you're automatically cross-platform from day 1. And not just in the kind of theoretical way you get with say PyQt where your application could be made to build on another platform if you spent a couple of hours fiddling with the build; the alternate-platform binaries are just there. That's powerful.
That doesn't actually solve the biggest problem. How do you package up that server? Can you make it something people can run like a regular executable on that platform? How do you distribute it?
The fact that you can't easily piggyback on the local browser irks me somewhat. If it's inherently a behemoth, maybe have it be reusable, i.e. piggyback friendly. You wouldn't want a per-app installation of Qt, for example, but even that would be less stressful on the system.
I have a lot of fantasies about how the web stack could be different. I guess that's reflective of some kind of frustration.
My impression was that with an offline capable web app you need CDNs et al to be reachable to load the web app, and then if connection was lost the app could handle it, but if you were to close and reopen the app, it would again need an internet connection to load.
Electron can target web/desktop/mobile but the results are far from optimal (RAM, CPU cycles... JS!).
I'm wondering if we might see more of JVM on desktops when the new low-latency GC engines become usable.