Why would someone use this when NW.js (formerly node-webkit) has essentially complete and native-from-using-Chromium (instead of libchromiumcontent) non-"polyfill" support for Chrome apps, and they consider it a supported platform feature as opposed to some third-party tack on (which isn't even trying to be fully compatible; as, in the README, this developer says he is refusing to implement chrome.socket to spec simply because he feels the API is "kinda crap")?
Not to disregard that NW.js might be a better choice in this case due to the API support.
But generally speaking, Electron:
- Is more tested in production (VS Code, Atom, [1])
- Has a larger and more active community
- Has (at least in the past) started using newer versions of Node and Chrome long before NW.js (Especially with Node when v4 came out this was a relevant drawback)
- Tested both the newest versions on Windows 10 right now, Electron used ~50mb less RAM, and less CPU. (Of course this isn't a very relevant test, more of an observation, these numbers could vary greatly between systems and platforms).
On the flip side, some reasons to use NW.js:
- "Source code protection", which gives a ~30% performance reduction. Electron devs has chosen not to implement this due to that drawback.
- Better support for transparent windows, at least in the past. (At the expense of disabling hardware acceleration).
Note that some of this information might be a few months out of date, mostly in regards to NW.js.
To address the "started using newer versions of Node and Chrome" point, since NW.js v0.13, on the day a new version of Chrome hits the stable channel, a new version of NW.js is released matching the Chrome version. At the time of those releases, NW.js ships the current stable version of Node. So as of late, NW.js has been ahead of Electron in being more up to date with Chrome and Node. There is also a corresponding beta version of NW.js that tracks the Chrome beta channel.
