If you wish to create a 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. In 2015, I released a first version of this comparison between the two tools. However, the release of version 0.13 of NW.js brought on so many improvements that an update became necessary. Hopefully, the chart and comments in this article will help you choose the right tool to build your next project.

This article was updated in July 2016.

I must confess that I have used NW.js quite a bit more than Electron, so this post may suffer from my own bias. Please (respectfully) leave your comments, suggestions and corrections to make this comparison as accurate as possible.

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.16.0	Electron 1.2.8
Project inception	2011	2013
Corporate Sponsor	Intel	GitHub
Licensing	Open Source, MIT License
Browser Runtime	Chromium	libchromiumcontent
Node.js Version	6.3.0	6.1.0
Chromium Version	52.0.2743.82	51.0.2704.106
Entry Point	HTML or JavaScript4	JavaScript
Bare Distribution Size	139MB (52MB zipped)	125MB (45MB zipped)
Windows Platform Support	Windows 7+ (x86 and x64)
Windows XP Support	In LTS version (0.14.x)	No
Mac Platform Support	Mac OS X.9 +
Mac OS X.6	In LTS version (0.14.x)	No
Architecture Support	32bit (Win), 64bit (Win/Mac) & arm (limited)
Chrome Apps Support	Yes	No
Support of chrome.* APIs	Yes	No
Plugin Support	NaCL, Pepper	Pepper
Adobe Flash Support	via Pepper Plugin
Mac App Store Support	Yes
Windows App Store Support	Yes	Windows 10+ (details)
App signing	Yes
Source Code Protection	V8 Snapshot1	ASAR Archive Support2
Auto-update	Unclear (module)	Mac/Win (thru Squirrel)
Crash Reporting	No	Yes
Kiosk Mode	Partial (Buggy on Mac5)
PDF Viewer	Yes	Using pdf.js
Native Node Module Support	Yes
SSL Client Certificate	Yes	Partial (details)
Print Preview	Yes	No
DevTools Extension Support	Yes
Debugging	DevTools + extensions	Dedicated Devtron Module
Integration Testing	ChromeDriver & WebDriver	Dedicated Spectron Module
Windows Installer	Yes (nw-builder)	Yes (external module)
html5test.com Score	492
Octane 2.0 Score3	27205	27343
Issue Resolution Time6
Open Issues6
GitHub Trends
Open Codecs/Containers	Vorbis, Theora, Opus, VP8, VP9, PCM, Ogg, WebM, WAV
Licensed Codecs	MP3, MP4, H.264, AAC7

1. If you are using a version smaller than 0.22, beware that this results in a 30% performance hit.
2. This is a very weak protection. It’s basically a TAR archive of all the project files. The Electron team decided against support for V8 snapshots. See details here.
3. Higher is better. Tests performed on Apple MacBook Pro Retina (Yosemite)
4. 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.
5. 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.
6. Data from isitmaintained.com: NW.js, Electron.

7. There is still some confusion here (see text below). Please perform your own tests.

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. 

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 a bit 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 automatically quit upon closing the last window. It is up to the developer to listen to window events and quit if wanted. 

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. Both have been chosen for large scale projects. Comparable examples are: Visual Studio Code (Electron) and Intel XDK (NW.js).

Legal Issues

The use of licensed codecs and demuxers/containers in both environment may feel like a gray area. The uncertainty is mainly caused by the FFmpeg licensing terms and the H.264 patent. The FFmpeg library is an open source project to encode/decode various audio and video formats. By default, Chromium (which is used with both NW.js and Electron) includes a version of FFmpeg compiled in a way that makes it compliant with the LGPL license. This means it can be used in both open source and proprietary/commercial projects. 

In Electron, the FFmpeg library is statically linked. In NW.js, it is not. This means that Electron offers out of the box supports for a wider variety of codecs. In NW.js, on the other hand, you need to manually link to FFmpeg. 

Update: this is all very confusing… last time I checked (July 2016), the MP3, H.264 and AAC codecs were all available when running html5test.com. This seems to mean they are now built in both projects… In any case, if that’s not true for you in NW.js, you can replace the ffmpeg library with the one found here.

So, if you use the vanilla Electron distribution, you shouldn’t have to worry about licensing issues. By the same token, if you link NW.js to a version of FFmpeg compiled with the default options (without the --enable-non-free  or --enable-gpl  options), you should be good to go too.

However, some codecs/formats might require royalty payments. This is beyond the scope of this document. 

 Other contenders

Another interesting option is Tint 2. It looks very interesting but, as I have not used it myself, I will have to try it and gather feedback from users before writing something meaningful about it. Meanwhile, here is how the authors describe it:

Tint enables programmers to create desktop applications with JavaScript by utilizing the node runtime with direct access to both native objects (Objective-C Objects and .NET/COM objects) or by using Tint’s built in application object model and API that standardizes GUI components across various operating systems. It’s a light-weight node runtime that integrates the application loop of the target operating system and safely exposes any native OS object needed to build an application.

If you are a Tint 2 user, you can share your feedbacks in the comments below. It should be noted that Tint (contrary to both Electron and NW.js) does not support Linux.

Conclusions

Considering NW.js’ longer track record and considering it has support for various features not present in Electron (Chrome Platform APIs, NaCL plugins, source code protection, PDF viewer, print preview, etc.), I would venture to say NW.js has somewhat of an edge.

One has to be prudent, though. There are reports of NW.js being buggy in the current transition period. Also, there are over 1300 issues on the NW.js GitHub that are currently untagged. While most of them are probably outdated and now irrelevant (some date back October 2012), the lack of maintenance is a bit worrysome. The NW.js team does not agree with my assessment, here’s what they had to say on the subject.

Having said that, both platforms are appealing and have a strong and active community. If the features you require are included, I don’t think you would go wrong with either of them. There’s also the matter of momentum. In 2015, Electron seemed to have momentum on its side. GitHub’s backing also gave it street cred. With the release of v0.13, NW.js is back with a lot of great features. 

If you disagree with my assessment, I invite you to leave your comments below. Please try to justify your position with facts and examples. I want this article to be as objective as possible.

Cheers!

 

---