There has to be a more efficient way of writing cross-platform code than bundling Chrome and NodeJS with your app.
Yes, it's called Freepascal using the Lazarus IDE. Native, cross-platform self-contained binaries that run fast and don't using oodles of memory or require massively-sized binaries.
Why is it not more widely used? Because of that word Pascal. That's enough to dismiss it in the minds of many developers. Modern Pascal has many of the features we associate with modern languages e.g OOP and generics. But Pascal's syntax, age and verbosity mean many developers will never give it a second look.
Better yet, why not make the architecture into a single shared "Electron windowing server" process that all Electron apps run "on", such that I don't end up running 7 different copies of Chrome?
(Honestly, Chrome itself could have become said runtime with its packaged apps, plus the (only ever experimental) standalone App Launcher install mode. I guess that's not the path they wanted to go down.)
You throwing everyone that uses node.js into a big bin labeled "only knows javascript cult" is childish at best.
There are obviously trade offs going with a "globally installed runtime" vs "including the runtime with each application". JRE takes the former, electron the latter. Each with their own set of problems, each providing different solutions, each with their own reasons, applications, and "target audience".
Not to mention the additional headache of having to install dependencies which can be an annoyance on some platforms.
At this point in 2016 the number of people that are negatively affected by an electron app's size on disk is significantly less than would be negatively affected by having to muck with installing "Electron Runtime version 52" for app A but need to lock it to "Electron Runtime version 50" for app B.
Also, I'm not so much concerned with size-on-disk as I am with
1. redundant versioning leading to redundant network bandwidth costs (e.g. I don't want to find out that I have 20 different apps that want to download a 100MB update—99MB of which is the same Electron binary—every time Electron itself updates.)
2. memory usage (30 versions of the Electron runtime means 30 copies of Electron taking physical memory. 30 apps using the same Electron runtime means 30 copies of Electron in virtual memory sharing the same physical pages.)
Also, some electron apps will modify the "browser" part.
As for download sizes, aside from the first download all updates can use Delta update packages and I believe this is built in.
Re memory usage, with sandboxing the way it is today I'm not convinced you would save all that much memory unless you were running over 10 different electron apps, and even then compared to the total memory usage I feel it would be insignificant enough to not warrant the "JRE architecture". I don't really have anything to back this up, its just a hunch.
And traditionally, management of such shared runtimes on anything but Linux sucks a lot. Remember all those Windows apps that tell you "Java Runtime Environment 1.5 required" and then they kind of leave you to figure out how to install that? Not exactly user-friendly.
And at the end of the day, regardless of your OS, you end up with 4-5 different JRE versions installed because compatibility is not perfect, so each app locks down to a specific version instead of accepting a newer JRE.
.NET isn't any better. I have 5-6 different .NET runtime versions installed and I can't remove any of them because each app requires a different version.
The method of vendoring all your dependencies may not be the most efficient, but it's certainly the most convenient one. It seems users these days care more about how much hassle it is to install than how long the download takes or how much RAM it uses.
Static linking the runtime also has significant downsides. One of the worst is how it puts the burden of pushing runtime security updates on the app. Frequent JRE downloads because of security patches is annoying, but downloading N copies of chrome every for all of your apps is insane.
Of course, this also requires that each app update itself to be compatible with the new versions every time there is a security patch. The entire point of including a specific version of chrome is to avoid these updates, so the very idea of Electron implies the app is not designed for security.
The thing that's big about Electron is it allows web developers to use their existing skills to create desktop apps.
A lot of web developers would like to make desktop apps, but aren't willing to learn a new systems language to do that, especially when there's a solution that lets them use the JS + HTML + CSS they already know.
And the beauty of Electron is that you can still write all your actual logic in C/C++ and use Node's FFI to bind it to your UI.
(Qt is transitioning to the same model with its HTML+JS based Qt Quick orchestrated from native code; but it's far less production ready than Electron right now.)
A developer that only knows js is unlikely to be competent (beginners aside).
Oh, don't get me started…
Yes, that's a problem. But Electron can hardly be blamed for it. They'd use XULRunner if it didn't.
Also it lets you reuse parts of your web app (or build part of your web app while building your desktop app). For something like Slack, or if Google were to make a desktop version of Docs, it makes a lot of sense to use Electron because you already have your web app and you want your desktop app to be consistent with it.
I've used Ionic with a very small team to make a web app and mobile app from the same codebase. The client asked if we could also make a desktop version for them, and instead of taking months to build one and make it consistent with the web/mobile apps, it was just a few days of learning to wrap it up with Electron. That was really neat!
It's really hard to beat HTML in terms of flexibility.