In my opinion, the primary driver for Electron is the Javascript runtime. Lots of people have Javascript experience and Electron makes it easy to use that knowledge to bang out a desktop-like application. The write once, run anywhere angle is compelling as well but that's how web browsers and Javascript work; sure Electron gets to enjoy this but it's a function of this technology stack.
I disagree that the comments pointing out the high CPU and memory usage are non-constructive. These are real issues that literally limit the number of Electron apps that can run at a time on a particular machine. Some Electron apps perform reasonably well, VS Code is a good example. But many perform abysmally and Electron is treading dangerous ground by going against the trend of limiting resource usage in order to extend battery life. Indeed, in my experience running a handful of Electron apps is a sure way to shorten battery life.
I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on... As others have pointed out, the best we could hope for is some sharing of the runtime that would allow more applications to run simultaneously.
You mention native languages that have a good cross platform story and I'd like to see some work toward a UI toolkit that is less demanding of resources. While people like Javascript, I do believe some of them will move to another language if they can do what they need to do: deploy to all OS environments with only minimal code changes. If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
I think you're right on many points, and I was more referring to the posts just complaining about it being in Electron at all as if Electron was some kind of bad word which should immediately trigger dismissal.
> I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on...
Here I meant native as in a natively compiled language. The browser is also invisible in this case, and the whole Electron model adds so many layers (which is part of the resource usage problem).
> If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
In this case I meant native as in blending in with the desktop environment, which I think Electron apps are more successful at than other toolkits (which are often natively compiled).
I find the appearance of Electron applications pleasing, I am not trying to take a crack at Electron when I say this: I don't think they are particularly native looking and I think this is an advantage to Electron. The point I was trying to make is that I don't think "looking native" is all that important anymore. Web applications seem to have trained people away from that "I can only click on things that look like buttons" straight-jacket.
I disagree that the comments pointing out the high CPU and memory usage are non-constructive. These are real issues that literally limit the number of Electron apps that can run at a time on a particular machine. Some Electron apps perform reasonably well, VS Code is a good example. But many perform abysmally and Electron is treading dangerous ground by going against the trend of limiting resource usage in order to extend battery life. Indeed, in my experience running a handful of Electron apps is a sure way to shorten battery life.
I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on... As others have pointed out, the best we could hope for is some sharing of the runtime that would allow more applications to run simultaneously.
You mention native languages that have a good cross platform story and I'd like to see some work toward a UI toolkit that is less demanding of resources. While people like Javascript, I do believe some of them will move to another language if they can do what they need to do: deploy to all OS environments with only minimal code changes. If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".