NW.js & Electron Compared (2016 Edition)

March 26, 2016 Jean-Philippe Côté
published in

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


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.


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.




  • Stefan Wrobel

    Thanks for the update!

  • Jonathan

    Pretty sure Electron supports native node modules. I’ve written a few myself.

    • Jean-Philippe Côté

      Of course it does! It’s probably a copy-paste error when I edited the table. Thanks for pointing it out. I fixed it.

  • Nick

    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 🙂

    • Jean-Philippe Côté

      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-throttling

      Because of the differences in architecture, it might not be as easy to do in Electron.

    • Joe Leonard

      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?

  • forward

    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.

  • GR

    Your table above claims that NW supports “App signing” but I haven’t seen that… am I missing something?

  • João Paraná

    Great post ! Tanks.

  • Guido

    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.


  • Matjaz Jurecic

    What does this mean:
    “1. Beware that this results in a 30% performance hit.”

    Performance hit on electron or nw-js?

    • Jean-Philippe Côté

      This is in the NW.js column so it relates to NW.js only. Cheers!

      • Jules

        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.

  • Khai

    Electron 1.0 has been announced, can you make another update?

    • Jean-Philippe Côté

      Unfortunately, I have very little time right now. Hopefully, when I get a little time I will update it. Cheers!

      • EL

        Thanks for the great post Jean. I would like to see an update after the Electron 1.0 release too please.

    • Jean-Philippe Côté

      Consider it done! 😉

  • GR

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

    • Jean-Philippe Côté

      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?

  • GR

    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.

  • GR

    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.


    • Jean-Philippe Côté

      I posted your challenge on the NW.js Google Group. Let’s see what happens…

  • GR

    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!

  • GR

    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:


    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!

    • Jean-Philippe Côté

      I’m glad it worked out. It should definitely be added to the documentation. I modified my chart to more accurately reflect reality.

  • GR

    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.

    • Jean-Philippe Côté

      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.


  • GR

    I would but I can’t have a Google account. As for Gitter… looks rather chaotic.

  • GR

    I’ve sent him an email…if I get a solution I’ll post it here so you can add it to your list.

  • Olumyco

    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…

  • ric

    what about crosswalk?

    • Jean-Philippe Côté

      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.


  • Hasa

    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

  • saghul

    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?

    • Jean-Philippe Côté

      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.

  • Tim

    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.

    • Jean-Philippe Côté

      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.

  • Slade

    NW.js has been ported to arm.



    • Jean-Philippe Côté

      Thanks for pointing it out. As far as I can tell, Electron and NW.js have about the same arm support now.

  • M Fathir Irhas

    Electron project inception in 2014?, isn’t it 2013?

    • Jean-Philippe Côté

      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.

  • englishextra

    Electron has a fetch problem. Have to use xhr to load json for instance

  • Tony

    Will there be an update for 2017?

    • Jean-Philippe Côté

      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! 😉

  • Bizi


    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…

    • Jean-Philippe Côté

      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.

  • Tim

    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.

    • Tim

      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.

  • Darren

    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.

  • Darren

    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.

  • Shawn

    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!

    • Nemi

      I would like to hear this also, is it good as Adobe AIR?

      • Jean-Philippe Côté

        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.

  • Jean-Philippe Côté

    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.

  • amhoho

    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.

    • Jean-Philippe Côté

      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…

  • Akhil Sahu

    Navigation is an issue on electron.

    • Jean-Philippe Côté

      Thanks for the comment.
      Can you be more specific about the navigation issues?

  • Nemi

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

  • Jaemin

    2017 is almost over.

    I’m looking forward to 2018 version.


  • charlie

    Today from isitmaintained:

    NW 5d (still)

    Electron 4d (up from 22hr)

    This metric may be due to maturity, seems equivalent

Post a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.