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.

An updated version of this comparison has been released in 2016. We encourage you to check it out instead of this one.

At this stage, the chart (and this article) 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.34.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 v?
ES6/2015 Support	Yes (all from V8 v4.1)	Yes (all from V8 v4.4)
Chrome-Equivalent Version	41	44
Development Model	Open Source
Licensing	MIT License
Entry Point	HTML or JavaScript5	JavaScript
Bare Distribution Size	75MB – 100MB4 (30MB – 34MB zipped)	To confirm. Anybody ?
Chrome Apps Support	Yes (in beta)	No
Support of chrome.* APIs	Yes (in beta)	No
Adobe Flash Support	Full NPAPI Plugin	Pepper Plugin
Mac App Store Support	Yes
Windows App Store Support	Yes	?
Support for Windows XP	Yes	No
Source Code Protection	V8 Snapshot1	ASAR Archive Support2
Auto-update	Mac/Linux/Win (module)	Mac/Win (thru Squirrel)
Kiosk Mode	Partial (Buggy on Mac6)
Windows Installer	Through nw-builder	Yes (external module)
html5test.com Score3	515	520
BrowserMark 2.1 Score3	5294	5643
Octane 2.0 Score3	27619	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. Unzipped. Depending on platform and architecture. See details in Jared’s comment below.
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 automatically 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.

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. 

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. If I get the chance, I will write a follow-up comparison article including Tint 2 . 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.

This 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. 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

It is hard to draw a final conclusion at this stage but most of the comments received so far seem to favor NW.js. Some of the reasons cited to choose NW.js are: longer track record, overall development philosophy, cross-platform auto-updater and Windows XP support. This conclusion section will definitely need to be refined when more feedback from the community will have been received. Where are the Electron fans? I know you are out there…

---