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)
xulrunner may be a superior technology, but if it's a PITA to work with, then nobody is going to want to use it.
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.
That's absolutley not true.
"Rapid Application Development with Mozilla" has been published before 2004. It is still online: http://mb.eschew.org/
XUL (and assorted technologies) is/were broadly documentet on MDN.
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.
Really?
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
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.