If you don’t already know, both projects are built on top of Chromium and Node.js, so that you can write desktop applications using Node.js at the system level (filesystem access, etc) and web technologies for the GUI layer.
Now, Electron has some advantages:
These are some reasons why someone would go with Electron. Now, let me explain why I would go in the opposite direction. NW.js — in my opinion — is better than Electron!
NW.js (LTS version 0.14.x) supports Windows XP and older versions of Mac OS. I know that even Microsoft has dropped XP support, but in many areas, many people are still using it (it has a huge market share in some countries). You can’t just tell your customers to upgrade! They won’t listen.
NW.js is more browser-oriented. You can set your
main entry to be an HTML file or a Node.js file, or even both (using
bg-script fields in package.json). In Electron, you have to use Node.js file and explicitly create your app main window and open it.
The approach of NW.js is a lot easier and more straightforward. It gives you many options. It allows you to do what you can do in Electron, but not vice versa.
The issue here is that NW.js Documentation on this point is very, very confusing. In fact, I wrote another draft blog post (will be published soon, hopefully) trying to clarify contexts in NW.js and how you can easily share variables and state between contexts and windows, in both modes: separate and mixed.
NW.js supports chrome.* APIs. Even better, you can run Chrome Apps/extensions using NW.js. Electron can’t (and won’t) do this.
NW.js supports PDF files out of the box, using Chrome PDF native plugin. It works so smoothly that you can even set
"main": "file.pdf" and it will work. You can display PDF files inside
<webview> , or just by pointing page
location to a PDF file.
Electron, supposedly, added this feature in version 1.6.4. However, it is very buggy (check: 01, 02). I have tried many ways (using Electron v3.0.8) to display a PDF file inside Electron (
<webview src='./file.pdf' plugins> and many others), but Electron keeps trying to download the file, not display it as expected. After an hour of searching around for a solution, I just gave up.
<script> tags) cannot be compiled using it. So, again, NW.js does a better job here, because their tool
nwjc) you can compile your whole application, even third-party libraries (like jQuery).
NW.js team is trying to keep up with Chromium version. So the day after a new version of Chromium is out, they will publish a new version of NW.js (with the latest version of Node.js that has the same V8 version as Chromium).
While you may not always need the latest Chromium release, many people do need that. It is clearly an advantage of NW.js.
Electron team, on the other hand, prefers to wait a few weeks or even months, before moving to a newer chromium version.
You can start NW.js with
NW.js also supports all Chromium Command Line Switches. For more information, check NW.js docs. These switches can be used to tweak and tune performance.
Electron, on the other hand, does not have
In Electron, you always have DevTools embedded in Electron binaries. It can be opened as easy as that:
In NW.js, you would use the “normal” build in production, which does not include DevTools (only SDK build does). If someone tried to open DevTools programmatically:
nw.Window.get().showDevTools(); , he would find a blank white screen.
Yes, theoretically he could have used an SDK build, to run your application, but you can prevent this scenario in your code (by checking if
normal, combined with source code protection, check № 6 above). You can’t do this in Electron (please correct me if I’m wrong).
If your application needs to print PDF files without headaches, you should go with NW.js. Printing works just as expected here, whether you are printing a webpage (using
nw.Window.get().print() function), or you want to print a PDF file (using the native print button, as Chromium does).
On the other hand, Electron users are struggling with getting printing function works as expected. There are many open issues in Github on this problem (e.g. #9029). See also this StackOverflow question, it has some insane workaround that tells you to use PDF.js (Ouch!) to render its content on a canvas, then print that! Other workarounds suggest using SumatraPDF (Ouch again!). Again, correct me if I’m wrong, I have a little experience with Electron.
The security model in Chrome (and web browsers in general) is a bit restrictive, due to the nature of your relation to the websites that you visit. Browsers do not allow websites to have an access to your filesystem, websites run in a sandboxed environment, and they are subject to same-origin policy … etc. While this makes sense in the context of web browsers and website, desktop applications need more.
NW.js provides another security model, that allows you to “Bypass all security restrictions, such as sandboxing, same origin policy etc. For example, you can make cross-origin XHR to any remote sites, or access to
<iframe> element whose
src points to remote sites in node frames”, according to NW.js Documentation. According to Roger Wang: “The list of things we can do in this model is expanding, and it might be good to ask for proposals from developers in [your] article. Issue reports like this are welcome”.
Compare this to Electron, which disables features like nested
<webview> tags (01, 02), because “it is a maintenance burden” and “it is not easy to get things right”. (by the way, you can nest
webview tags in NW.js as you want, but for local HTML files, you have to add a permission in
Finally, I’m a little biased towards NW.js. I hope this bias did not affect the accuracy of my article. Any comments or corrections are more than welcome.