NW.js & Electron Compared (2016 Edition)
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!
72 Comments
Thanks for the update!
Pretty sure Electron supports native node modules. I’ve written a few myself.
Of course it does! It’s probably a copy-paste error when I edited the table. Thanks for pointing it out. I fixed it.
Great write up! I tried to run Tint2 but nothing happened on my PC. I posted an issue in their Github.
I’ve been using Electron for several months now for my action rpg game. It’s about 100k+ LoC big using Phaser’s Game Engine and CSS/HTML/Nodejs modules for client patching (fs, adm-zip, etc).
There is an issue with the RequestAnimationFrame inside libchromiumcontent it’s nothing to do with Electron, but when an app is minimized, the RAF doesn’t update. And for my game being multiplayer and having physics tied to RAF.. this is a must. I’m currently trying to find a way to disable that inside chromium but have no idea. I posted the suggestion here: https://bitbucket.org/chromiumembedded/cef/issues/1864/adding-requestanimationframe-to-disable but it seems like I posted in the wrong area…. so I kind of just give up with it all.
Electron has been great, and there is currently a PR on their Github that is addressing this RAF issue. https://github.com/atom/electron/issues/4925#issue-143770188
Which should make the command –disable-renderer-backgrounding work for RAF as well. I think Cheng Zhao is doing an amazing job and hopefully can patch that in.
The RAF thing with Chromium is an issue I think that is only good for browsers. We are advancing now though with WebGL and 2d Gaming. So I hope they do get it to work and can understand why we need our game running in the background. Yes, I could go through Web Workers with SetInterval to update the game logic.. yes I could make my server not send messages to a client if they are minimized.. I could do all that but seriously? Just let us choose to not have RAF disabled on minimized windows! 🙂
In any event. In my experience, electron is amazing and nw.js has a weird 1-3 second startup delay sometimes. I’m on a stock W7, 64 bit Pro OS, so not sure if that has anything to do with it. But I will continue to electron for our upcoming game, but right now I’m trying to find something that doesn’t use Chromium. I was looking into EDGEHTML (I was going to just DL Visual Studio and embed it as a Web Control Frame, but.. it’s only working for Windows 10 clients), which is not ideal. And Tint2 is not really working.. so I’m really stuck right now, I’ll continue to develop on Electron but hope one day that RAF issue get’s fixed or atleast give us an option. Their team are great people so I shouldn’t worry that much 🙂
–Nick
Sorry for teh horrible typo’s grammar. I just basically went all out and didn’t edit 🙂
Thanks for the write-up. I guess you know by now but the problem has been fixed in NW.js two days ago. You can simply use the following command-line switch:
--disable-raf-throttlingBecause of the differences in architecture, it might not be as easy to do in Electron.
Nick, I’m curious about what games you created. I also made a simple action RPG called Nevergrind. I have moved on and I’m currently developing a grand strategy game called Firmament Wars. I have always wanted to create installed versions of these games, but I haven’t attempted to do so quite yet. What kind of stumbling blocks should watch for? How’s the performance?
Does anyone know if either electron or nw.js have the ability to render video using the VA-API (Video Acceleration API) to enable hardware accelerated video decode in Linux? Particularly on Intel devices. I know ffmpeg supports this although with a regular chromium browser build and install I had to jump through a few hoops to get this working. Such building it with chromeos support and making sure its not running the the sandbox.
Your table above claims that NW supports “App signing” but I haven’t seen that… am I missing something?
I have not done it myself but there’s a page about it in the wiki: https://github.com/nwjs/nw.js/wiki/MAS:-Signing-the-app
It slightly changed. This was the signing valid for version 0.12.3. Since 13.0 there are some changes. I will contribute my script when I find the time. But it works
Thanks for the precisions, Mislav. Keep us posted.
Great post ! Tanks.
Hey App signing works just fine in Electron. If you use electron-builder is really easy to do it, I wouldn’t say this is unclear.
https://github.com/electron-userland/electron-builder
Thanks for pointing it out. I’ve updated the chart.
What does this mean:
“1. Beware that this results in a 30% performance hit.”
Performance hit on electron or nw-js?
This is in the NW.js column so it relates to NW.js only. Cheers!
30% sounds like quite a hit for “compiled” code. However, assuming I have interpreted the documentation correctly, if you have anything which is performance orientated (big loops and the like) you can leave that outside of the compiled scripts and have it as a regular JS file.
Electron 1.0 has been announced, can you make another update?
Unfortunately, I have very little time right now. Hopefully, when I get a little time I will update it. Cheers!
Thanks for the great post Jean. I would like to see an update after the Electron 1.0 release too please.
Consider it done! 😉
No end to NW bugs…
NW v0.15 Bombs out of memory in Win7 for undetermined reasons.
NW v0.15 Back to old problems with bad drop-shadowing… Chromium is the culprit here I think.
NW v13.5 to v0.14 Can’t handle secure sites in iframe – DNS issues and/or bombs out of memory.
All NW versions: Cannot get MP3 or MP4 support, can’t add any plugins anyway!
NB: I’m working on a browser so I get to see a *lot* of NW problems and unfortunately there are far too many. I’ve got two major projects done with NW but I can’t release them because there’s no trust… too many bugs. 🙁
Thanks for your feedback. There seems to be issues during the current transition phase to the new architecture…
Regarding mp3 and mp4 support, there is a page in the NW.js documentation that explains how to do it. Is the procedure described not working?
I can’t understand Chinese-English so that page is useless to me and to this day I honestly don’t know of *anyone* who has managed MP3/MP4 support in Windows under NW.
Btw, I think you should remove the “MP3/MP4 support with some effort” for NW because one could argue that with “some effort” one can build a jumbo jet or an aircraft carrier so “some effort” is meaningless and misleading.
The truth is that NW *DOES NOT* natively support MP3/MP4 (I suspect because there’s no such thing as a PPAPI MP3/MP4 plugin so far, but only in NPAPI format which Chromium threw out the pram along with its nappies) and I challenge anyone out there to prove me wrong by pointing us to a recent NW Chromium project that handles MP3/MP4s internally.
Please make my day by proving me wrong.
Thanks.
I posted your challenge on the NW.js Google Group. Let’s see what happens…
Thanks! I PRAY that it’s possible because I have a beautiful browser on hold that simply cannot compete with the competition if it can’t even handle MP3/MP4s!
Far out! It *DOES* work when you replace the stock ffmpeg.dll with the one on the link you were given!
They’ve been hiding that page from us for years! Not a mention of that link from NW!!!
And here’s a good site to test a plethora of audio/video formats online including H264:
http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm
Amazingly, most work!
However, it doesn’t register as a plugin or a MIME type of any kind, so I have no idea how this works but I’m not complaining and I don’t care how it works!
Massive problem solved! I’m ecstatic…
PS: Don’t ever lose that link!
I’m glad it worked out. It should definitely be added to the documentation. I modified my chart to more accurately reflect reality.
Be sure to thank that guy for his great link when you find the time, and please also ask in that thread how we can get WebGL support in NW.
The default WebGL status in NW returns “Supported but disabled” and I’ve no idea how to get that to work, if at all possible. Thanks.
Yep, I did thank him.
Regarding WebGL support, I invite you to do as I did and ask your question on the NW.js Google Group. Another option is to try asking on Gitter. Surely, someone will be able to help.
Cheers!
I would but I can’t have a Google account. As for Gitter… looks rather chaotic.
I’ve sent him an email…if I get a solution I’ll post it here so you can add it to your list.
Excellent, thanks!
Nice Article.
Pls anyone… I av a swf file (flash) that I run on a NW.js app for animation stuff. What I discovered was that the swf runs on my system bcos I av flash installed but does not run in some other pple’ s system….. So I want to ask how I can I do it such that it runs in other systems when they install my NW.js app…
Thanks
Did you try the procedure described in the documentation?
what about crosswalk?
Crosswalk is very interesting. However, this is an article about creating desktop applications. With no support for Mac OS X, Crosswalk pretty much disqualifies itself.
I wanna make some distributive desktop apps, does NW.js possess some kind of a builder that would make an installer. Also, for now all this node JS awesome exploitation seems to really complex to me in this lvl. Where are the best sources so I may reduce that learning curve
Check out the NW.js documentation for pointers on app distribution. For Node.js, grab a book or one of the countless tutorials available on YouTube.
Great comparison, thanks for keeping up to date!
The NW.js column mentions Windows XP+ support, but since Node 6 no longer supports XP, does that still stand?
The LTS (long term support) version (0.14.x) is scheduled to be supported all the way through somewhere in 2018. As stated in the release notes, this version will stick with Chromium v50.x and Node v5.x. This means we will still have official Windows XP support for two more years. Obviously, you cannot use the newer 0.15+ versions on Windows XP.
I was siding with electron for the last year but recently NW.js has come out on top for me.
The chrome.* API’s mean I now have reliable serial port comms without native node modules (which have been unreliable at best) and can even support bluetoothLE on chromebooks.
Native serial support is the reason why I’m using it for physical computing projects. It makes it so much easier to connect to microcontrollers such as the Arduino than using native-based Node modules.
The new WebUSB API might make all this even easier though.
NW.js has been ported to arm.
https://github.com/jalbam/nwjs_rpi
Thanks for pointing it out. As far as I can tell, Electron and NW.js have about the same arm support now.
Electron project inception in 2014?, isn’t it 2013?
Hmmm… I don’t recall why I came up with 2014 as the inception date. The first release of “Atom Shell” came out in July 2013. The first release of “Electron” actually came out in April of 2015. But, in all fairness, I guess you are right. The project changed name but it’s still the same project. I’ll update the chart to say 2013.
Electron has a fetch problem. Have to use xhr to load json for instance
Will there be an update for 2017?
Hello Tony! That would be an excellent idea. Unfortunately, I’m swamped with teaching, workshops, conferences, etc. Hopefully, I’ll get to it before the end of the year! 😉
Hello
i am starting in java and i would like to know how to do my business logic in java and couple it with electron gui…
By “java” do you perhaps mean JavaScript or do you mean actual Java? If you really mean Java, I know there is a Node.js java module which may help you with what you’re doing.
I recently converted our large app from nw.js to electron.
Our main motivations were:
The last two are key. We can build and package on any platform from a single CLI command and spectron gives you so many more options than simply using webdriver.
Also, asar makes installation so much quicker. On Windows the installer only has to copy the single asar file whereas for nw.js if you don’t want the performance impact of snapshots, it had to copy many, many tens of thousands of tiny files which took forever.
Thanks for this very valuable input!
In the second paragraph under the heading “Paradigm” you start out talking about Electron then move into NW.js. It’s very confusing especially as the third paragraph then seems to go back to Electron! ????
Other than that it seems a very good article.
Electron issues are now up to 4d to resolve and 7% open. Also the link to isitmaintained for Electron is broken. It should be http://isitmaintained.com/project/Electron/electron.
Fixed. Thanks for reporting it.
I am considering using nwjs as a replacement for when I would have used Adobe Air. Would you be able to comment on nwjs performance and stability as a touchscreen kiosk when compared to Air? It would use basic animations, sliding, fading, etc and possibly have a need to scroll text by touch & drag. As well as download and cache files. Thanks for any input you may have!
I would like to hear this also, is it good as Adobe AIR?
My experience so far is that it is not as tightly integrated as Adobe AIR but you can still manage to do everything AIR does. In fact, there are much more libraries and tools for the web platform (front end + Node) than there are for AIR.
As far as I know, NW.js is very stable for kiosk use. I used it to run a CreateJS-based project (with StageGL) and performance was great.
Electron 1.6.8 and Nw.js 4.2 has been announced now, can you make another update? I do not know which one is better suited to myself.
NW.js 4.2 ?! Are you sure about that? 😉 Anyway, I really should update the comparison but it does take quite a bit of time to do it…
Navigation is an issue on electron.
Thanks for the comment.
Can you be more specific about the navigation issues?
from https://software.intel.com/en-us/intel-xdk:
The Intel® XDK mobile app cloud build service is deprecated and was disabled at the end of June 2017.Learn how to use Apache Cordova CLI or Adobe PhoneGap Build
Notice
You can use Intel XDK to create IoT applications with JavaScript*. However, the Intel XDK mobile app cloud build service is no longer available. Refer to the product documentation for information on how to export and build mobile apps using Adobe PhoneGap* or Apache Cordova CLI*.
2017 is almost over.
I’m looking forward to 2018 version.
Thanks
Yeah… I know. Time flies. I’m not making any promises…
Today from isitmaintained:
NW 5d (still)
Electron 4d (up from 22hr)
This metric may be due to maturity, seems equivalent