electron eats so much cpu & memory simply because it's still a web browser, it has to support all those 20 years of HTML/CSS history and it was designed to do so for 10s of tabs, so it has a lot of caches and other things.
and while javascript is certainly one of the worst choices if you care about performance, it's also one of the best choices if you need to iterate really quickly (which I believe is very important in overall, especially for new projects)
I hope there will be lighter electron one day (I'm actually working on something like this already) but it's unlikely that people will start doing UIs in systems languages.
> electron eats so much cpu & memory simply because it's
> still a web browser, it has to support all those 20 years
> of HTML/CSS history and it was designed to do so for 10s
> of tabs, so it has a lot of caches and other things.
XULRunner does the same thing, includes, in addition, a full XML GUI language and assorted technologies and the full runtime distribution, on my Windows10 system, including debugging, crash-reporter aids, VC libraries, D3D libraries, consumes 72MB.
it's nowhere near to XUL but it's also little more powerful because of react (vdom is more dynamic than XML, it will be possible to use react-devtools and it should support HMR too)
I haven't used electron, but in 2007 xulrunner was such a pain in the ass to write code for it wasn't worth the effort for anything where you didn't absolutely need an embedded browser, and even then there were better options.
Documentation was poor or non-existent and IIRC the API was based on the half-baked XPCOM because COM and CORBA were all the rage at the time it was created.
Wasn't xulrunner based on XPCOM which Mozilla deprecated? I think this is one of the technical reasons for its decline, but I think the biggest reason was timing.
When xulrunner was being developed there wasn't the same interest in desktop software. It seems like Chromium reached a point where you could build desktop-class software, but the distribution model wasn't right. Someone then decided to adapt Chromium to solve the distribution problem and you have Electron.
If Firefox had evolved to allow the tipping point experience that Chrome did, then you might well have seen xulrunner be that thing. It was years ahead of itself, but perhaps you could question the focus of the folks on the Mozilla side who were spread across so many concepts/ areas compared to the folks at Google - but I think that's for a different thread.
JS had nowhere the popularity it had today. At the time, creating a desktop app in Javascript was not regarded as serious. The reason electron became popular is because so many people from other fields (designers, integraters, students...) learn programming through copy / pasting JS and wanted JS for everything. Hence node. And now electron.
They didn't advertise that much, though. I only learned about XULRunner when I was trying out a keyboard-driven browser (Conkeror). Unlike Electron, XUL wasn't promoted.
uh, I wouldn't say electron got popular because of copy-pasting newbies.
webapp development is a lot of work and SPAs are actually even harder... and so is server development with node. I love javascript, yet I don't think it's suitable for everything.
electron got popular, because companies could reuse code and tooling, only for the cost of cpu & memory
Because the runtimes aren't meant for small, high-performance app, and the language itself doesn't (or wasn't, until recently) give you the primitives necessary for writing high-performance code.
automatic memory management makes certain optimizations very hard to do (you can't make cpu-cache-friendly array of structs)
javascript is very dynamic and V8 has very limited time to make its magic so the optimizations can't ever reach level of rust/c++ (but V8 can do some runtime-only optimizations)
it's very hard to predict performance of given code (and this itself is why it's the worst choice for perf-sensitive code, V8 is moving target, and what was fast yesterday might be slow tomorrow - so basically, it's not worth time and money to actually spend too much time optimizing javascript, it's much better to identify hot spots and do them in rust/c++)
It usually doesn't matter and it's more than fast enough for any kind of scripting, but it's certainly not a good fit for cpu-heavy tasks. I love javascript, to be clear.
BTW: run some node.js code with --print-opt-code so you have an idea how big amount of code is generated even for very simple things.
and while javascript is certainly one of the worst choices if you care about performance, it's also one of the best choices if you need to iterate really quickly (which I believe is very important in overall, especially for new projects)
I hope there will be lighter electron one day (I'm actually working on something like this already) but it's unlikely that people will start doing UIs in systems languages.