NW.js & Electron Compared
If you wish to create a native desktop application from web technologies, the open source world offers two main choices: NW.js (formerly node-webkit) and Electron (formerly atom-shell). Deciding which one to go with is not so obvious. That is precisely why I created the comparison chart found in this article. Hopefully, it will help you choose the right tool to build your next physical computing project.
At this stage, the chart is a work in progress and needs help from the community. As I have used NW.js quite a bit more than Electron, this post probably suffers from my own bias. Please (respectfully) leave your comments, suggestions and corrections to improve it.
In addition to the chart, I will also compile a list of various other key differences that may influence a first time user’s choice. Again, your input is most welcome.
The Chart
| NW.js 0.12.3 |
Electron 0.31.1 |
|
| Project inception | 2011 | 2014 |
| Sponsor | Intel | GitHub |
| Platform Support | Mac, Linux & Windows | |
| Browser Runtime | Chromium | libchromiumcontent |
| Layout Engine | Blink / WebKit 537 | WebKit 537 |
| JavaScript Engine | V8 | |
| Node.js Engine | io.js v1.2.0 | io.js |
| ES6/2015 Support | Yes (all from V8 v4.1) | Yes (all from V8 v4.4) |
| Chrome-Equivalent Version | 41 (44 in v0.13a3) | 44 |
| Development Model | Open Source | |
| Licensing | MIT License | |
| Entry Point | HTML or JavaScript5 | JavaScript |
| Bare Distribution Size | Between 90MB and 120MB4 | |
| Chrome Apps Support | Yes (in alpha) | No |
| Support of chrome.* APIs | Yes (in alpha) | No |
| Mac App Store Support | Yes | It’s complicated! |
| Windows App Store Support | Yes | ? |
| Source Code Protection | V8 Snapshot1 | ASAR Archive Support2 |
| Auto-update | Mac/Linux/Win (module) | Mac (Win thru Squirrel) |
| Kiosk Mode | Partial (Buggy on Mac6) | Partial (Buggy on Mac6) |
| Windows Installer | Through nw-builder ? | Yes (external module) |
| html5test.com Score3 | 515 (521 for v0.13a) | 520 |
| BrowserMark 2.1 Score3 | 5294 | 5643 |
| Octane 2.0 JS Benchmark Score3 | 27619 (28684 on v0.13a) | 28346 |
| GitHub Trends | ||
| Open Codecs/Containers | Vorbis, Theora, Opus, VP8, VP9, PCM, Ogg, WebM, WAV | |
| Licensed Codecs: MP3, MP4, H.264, AAC | Yes (with some effort) | Yes |
1. This results in a 30% performance hit. It is unclear if it is supported in version 0.13.
2. This is a very weak protection. It’s basically a TAR archive of all the project files.
3. On a MacBook Pro Retina running Mac OS X.5.5 (Yosemite). Higher is better.
4. Varies with platform and features. Detailed analysis would be nice if someone has time…
5. This can be done by using the “node-main” instruction in the package.json file or (in version 0.13 and above) through the Chrome Apps manifest file.
6. Kiosk mode is enabled upstream by Chromium. If you would like the Chromium team to improve kiosk mode support on Mac, please vote for it.
Additional Comparison Elements
Paradigm
It is a bit of an over-simplification but broadly speaking, NW.js’ paradigm is more browser-oriented. It basically loads the specified HTML page and that page gets access to the Node.js context. If more than one window is opened, then they all get access to that shared Node.js context. This means that it can be directly accessed from the DOM of all open windows transparently.
With the upcoming support for Chrome Apps in NW.js version 0.13, it will be possible to use a manifest.json file pointing to a JavaScript file in the manner described in the Chrome Apps documentation.
Electron, on the other end, has more of a Node.js-oriented approach. It starts a Node.js runtime which then has the ability to open windows into which you can then load web pages.
In more technical terms, this means that the NW.js team has to insert some hooks in the Chromium codebase so it can plug in the Node.js environment. While this requires more work from the NW.js developers, it means the browser and Node environments interact in a more seamless way.
Electron does things in a very different way. A main process is started and that main process can open windows with separate renderer processes. This means that communication between windows or between the main process and the renderer processes is harder. A concrete example of that is trying to modify the menus (created in the “main” process) from the code in one of the windows (renderer process). To do that requires data marshalling through IPC communication.
Another consequence is that, unlike NW.js, Electron will not quit upon closing the last window. It is up to the developer to listen to window events and quit if wanted. I guess this could be positive or negative depending on your needs.
Track Record
Electron is the new kid on the block but many applications have already been created with it. NW.js has been around longer and, from what I can tell, has been used to develop more projects.
It should be noted that NW.js is currently in a transition period because of the integration of the Chrome Apps APIs but everything should fall back into place with the final release of version 0.13.
Media Support
The use of licensed codecs and demuxers/containers in both environment still feels like a gray area. Chromium itself does not include support for proprietary formats. However, the Google Chrome app build does include support for MP3, MP4, H.264 and AAC. This is all related to the ffmpeg library that is used for such formats. In Electron, this library is statically linked and those proprietary codecs become available. However, as per the ffmpeg licensing terms, an app that statically links to ffmpeg should be licensed as GPL just like ffmpeg itself. Is an application that is built on another application that statically links to the ffmpeg library free of such license requirements? I would think not but I honestly do not know. Furthermore, ffmpeg can be compiled with various licensing flags that actually modifies the licensing terms. Can it get any more confusing than that ?!
NW.js decided to not statically link to the ffmpeg library. This means that, out of the box, you do not get support for MP3, MP4, H.264 and AAC. However, you can manually link NW.js to the ffmpeg library that is shipped with the matching Google Chrome release and you should get access to those codecs… That’s a hassle but it should work. Beware that the same licensing restrictions apply, though.
In any case, if you make money with an app that uses a license-encumbered codec, expect to pay a license fee or royalties to someone, somewhere… If anybody can provide me with a better perspective on the situation, please comment below.
Stuff that should not matter but still does…
For a project that has been around for a while and that is used by so many people, it is a bit surprising that NW.js does not have a proper website. It does have very decent documentation on the GitHub wiki but when you look at Electron’s website, you can’t help but think that Electron must have the edge.
As far as I’m concerned, Electron also has the edge in terms of branding. It has a clean and simple logo that does not have the outdated, web 2.0 look of NW.js’ logo. And what about the name ? Electron is cool, simple and memorable while NW.js is a bit cryptic.
As I said, this stuff should not matter but, in many ways, it does. That is especially true for people first encountering those projects.
Conclusions
Definitely to be completed when more feedback from the community will have been received.
22 Comments
nwjs is my choice, although one problem, from my own point of view, right now is the out of the box lack of direct support for mp3, aac and other multi-media formats.
This boils down to a legal issue, I know, but it could and should be corrected going forward.
As of now I have no choice but to release on 12.3 and go no further because of this one issue.
As for Electron, they need more ‘time in the saddle’. I’m not really keen on their choice of direction insofar as overall development philosophy is concerned and doubt I’ll change from using nwjs.
Anton, thanks for your comments. The codecs/demuxers licensing issue is frustrating. At least, it’s possible to get it working in NW.js 0.12.3. In Electron, it is now built-in. The legal impacts of that decision are still unclear to me though.
The products themselves are not subject to a custom license, both are MIT licensed.
Thanks for your comment Martin. You are absolutely right. Since the LICENSE files from both projects’ GitHub repositories had no reference to MIT or other standard licenses, I wrongly assumed they were some sort of custom license. I was wrong. I fixed the chart accordingly.
Thank you for sharing this!
Can you go into more detail about overhead, design mechanism, and APIs involved?
For example, memory usage. I’d really like to understand the specifics about the internals, so I can get a feel for how well the io.js and browser are coupled. And how robust are the frameworks and builtins. Trying to think in terms of sustainability and extensibility.
Great job on the info.
I wish I could share more info. Unfortunately, I’m not involved directly in the projects nor part of the development teams. I, myself, would love to know the answers! You could try posting your questions on each team’s discussion forum:
If somebody answers, I’ll relay the info here. Cheers!
NW.js has had support for starting from a JavaScript file for ages. In the package file, you put in a “node-main” option that points to the script file to run, and you set “window” -> “show” to false.
Moshe, you are so right! I never realized this was available. I guess it’s a good thing I publicly called for help in making sure my data was sound ;-). I’ll change the chart. Thanks!
Electron does indeed have MP3 & MP4/H.264 support. I just tried both.
Also note you don’t need to ship ffmpeg with an Electron app because it’s statically linked as of v0.31.0: https://github.com/atom/electron/releases/tag/v0.31.0
Josh,
Thanks for pointing that out. Obviously, you are right (I tried it myself too). I was thrown off by comments in the forum regarding mp3/mp4. However, since ffmpeg requires in its license that applications developped with it be GPL-licensed, I’m unclear as to what that means for Electron-developed applications. It’s probably okay but… who knows?
Good tip! I posted a little something in the nw.js thread you started.
As I figure things out, I’ll send it your way!
Excellent! Thanks.
Hi Jean,
One thing that I realised is that you focused more on the internals of each, but I believe the biggest selling point of electron is it’s out of the box features that you didn’t mentioned, on what their site they call as “The hard parts made easy”, which includes: Automatic updates, Crash reporting, Windows installers…
I’ve used a lot of NW.js in past (when it was node-webkit) and automatic updates and windows installers can be a big deal.
That said I never really used Electron that much to see how easy is to use those features, but as a consumer those are important points that I would take in consideration when using then.
Wilker,
You make a very good point! I must admit I’m not too familiar with those features myself. I’ll do some digging and add them to the chart.
Thanks!
I did a bit of research and it turns out that NW.js might have better auto-update support than Electron. There is a module for NW.js called node-webkit-updater that supports auto-update on Mac, Linux and Windows. I have not tried it myself but judging from the 300+ stars on GitHub, I’m guessing some people have. Electron natively supports auto-update on Mac. For Windows, you will have to rely on Squirrel. The grunt-electron-installer module will let you build a Windows installer using Squirrel.
Support for Windows installers on NW.js remains unclear to me. It might be possible to create one with nw-builder (that remains to be confirmed).
And one more thing about Electron: it doesn’t support XP nor Win2003. I know that market share of XP is about 4-5% but NW.js supports and it may hurt in corporate segment, where XP is still alive
Andrew,
Are you sure about Windows XP support? I thought Chrome/Chromium itself dropped support for Windows XP earlier this year. Do you have a spec or an article I could link to? I could add it to the post.
Thanks!
You know, Enyo (http://enyojs.com/get-enyo/) is another option for complete cross-platform/browser coverage, as well. It is in flux at the moment, switching to a require-style system in ver 2.6. You should check it out.
sugardave,
Enyo looks like an interesting project. However, unless I’m mistaken, it is not in the same category as Electron and NW.js. As far as I can tell, Enyo is simply a webapp framework that can be packaged. It does not seem to provide the native APIs (filesystem, processes and devices access) offered by NW.js and Electron (at least not beyond Cordova and Chrome Apps). Am I wrong?
Ah, you are correct, I am guilty of skimming your article on the airplane. There is no native hardware/sensor access for platforms outside of cordova (or the like) by design. Oops 😀
Awesome chart. I would like to know how the projects compare with respect to the following:
Do they both start a web server to deliver content to libChrome?
Or, do they operate without an internal web server in the loop?
Josh,
There is no web server involved. The pages are parsed just as if you had opened them locally. What’s exciting is that even though no webserver is involved, you still get full access to the local machine through the Node.js APIs which are directly available in your DOM JavaScript code.
Cheers!