Electron vs nwjs

I have recently been digging into Electron and nwjs as options for deploying a web application to desktop computers as an installable binary. While both are similar technologies utilizing Node.js and Chromium, I have noticed some subtle differences that affect my development workflow (beyond just purely technical differences).

UPDATE: I wrote a follow-up to this post!

Playing Field

In full transparency, here are the exact versions of both tools that I’m using:

  • Electron v0.25.2
  • nwjs v0.12.0

At the time of this writing, these are the latest versions of both.

The electron repo has a good document defining what they believe to be the differences between electron and nwjs — be sure to give that a read. For me, those technical differences didn’t really affect my decision towards either tool but they’re definitely worth noting.

Build Output

Both electron and nwjs are really easy to get started — I had a running app within minutes in both tools.

However I did notice a gigantic difference in file size for the “production” builds I created. Both projects have decent documentation on creating a rebranded binary on multiple platforms — and for my app (18MB compressed static web content) the clearly smaller build output came from electron (117MB total for OSX, with no asar compression), while nwjs created a huge 220MB binary for OSX (no V8 snapshot).

That’s not a scientific study on these tools, and it’s certainly possible I’m not optimizing some things perfectly… but the 18MB of static web content (my app) is then wrapped in a rather sizable (100/200MB) of extra stuff.

Furthermore, my app seems to launch faster in electron — which may just be the result of starting in the Node context (electron) compared to starting in the Web context (nwjs).

Build Process

On the other hand, creating a rebranded binary across platforms seems much easier using nwjs.

I use grunt for my local build process, and nwjs has a ton of grunt plugins to make this process smooth and easy (although I didn’t actually try to build a Windows executable).

electron has some grunt plugins — but they’re not updated frequently, and the usage is confusing. In particular, grunt-build-atom-shell is super confusing as you have to tell it what tag/commit of electron to use IN ADDITION TO the magical custom version of Node that tag/commit depends on. Because I obviously know that.

Protecting Source Code

In nwjs you can build an executable using a V8 snapshot of some kind. I didn’t really dig into what that is or how it works, but the repo makes it clear that you’ll take a 30% performance hit. Ouch.

In electron, you can build using an ASAR archive. This is really, really easy to do — and there’s a great grunt plugin for that! On the downside, I have to imagine that an ASAR archive can be cracked relatively easily… but it’s better than plaintext.

And the winner is…

At the end of the day, I’m moving forward with electron. I like that it’s officially sponsored by GitHub — and Visual Studio Code was just released using it, so that’s a pretty good endorsement!

The custom branded binaries will be a bit problematic for me, but the rest of the build process isn’t bad. Certainly the smaller size of the final executable is a plus!

What are your thoughts?

Is anyone out there using these tools? What are your thoughts?

Please feel free to offer some insight on your experience — I’d love to know if there are other considerations I should make, or if I’m not doing things the best way.

About 

With nearly 20 years of software engineering and operations experience, Arthur Kay offers an extraordinary set of leadership skills and technical expertise to develop meaningful products and high-performing teams. He has worked with Fortune 500 companies, VC-funded startups and companies across a wide variety of industries to build cutting-edge software solutions.

Arthur is a successful entrepreneur, technology professional, and mentor. He is a full-time family man, part-time consultant and spare-time musician. He graduated from Loyola University Chicago and currently lives in greater Chicago-land.

13 comments for “Electron vs nwjs

  1. Nate
    June 25, 2015 at 3:38 pm

    Nice article. I ran some tests with NWJS and Electron as well for running a Sencha touch app, and also came to the conclusion that if it’s good enough for Microsoft, it’s good enough for me. So far, however, I have run in to one major problem. Sencha touch carousels don’t seem to work very well in Electron (on OSX Yosemite). Did you have any luck with them?

    • Arthur Kay
      June 25, 2015 at 3:43 pm

      I can’t say that I’ve tried Sencha Touch Carousels specifically, but I don’t see why they wouldn’t work. Open a thread on the Sencha forums and paste the link here… I’ll see if I can help you debug.

  2. June 26, 2015 at 3:47 pm

    Thanks for a nice comparison! Much appreciated because of the regrettable consequence of OSS: Multiple tools doing almost exactly the same thing. I wish they could cooperate instead.

    • Arthur Kay
      June 26, 2015 at 3:59 pm

      Yes, that’s a frequent frustration for me as well. Should you use Cordova? Electron? NWJS? Something else???

      On the other hand, the “competition” between projects is a good thing because it means we (as an OSS community) are constantly striving for “better” tools and are willing to question why one approach was chosen to begin with. At least we aren’t arguing about which tool is “better” — that happens all too often in OSS.

      The reality is that you’ll never really find an unbiased, well-informed opinion (mine included). I’m just happy my opinion resonates on this particular issue.

  3. June 27, 2015 at 8:35 pm

    Well, in competition there’s usually a winner and a loser, and a bunch of people trying to bet on the opposing sides. With the increasing “value” put in OSS (VC, time, marketing, usage in commercial software, etc), losing such a battle can have bigger consequences than what it once had.

    I wish we could avoid such situations, but the increasing number of big project forks seems to indicate that opinions are becoming more important than cooperation and sound research… An example on a larger scale: The DCI architecture is a way out of today’s limiting way of system design, focusing on interactions between objects (real OO instead of what we do today, class-orientation). It is created by the author of MVC, has been slowly evolving for 10 years and is now incredibly well-researched compared to other “bright ideas” that people blog about on a whim. If you’re interested, here’s a tutorial of mine: https://github.com/ciscoheat/haxedci-example and much informative material here: http://fulloo.info/Documents/

    There’s not much interest in DCI though, despite all its well-grounded research, and my theory is that it gives too many answers, which means that many people will be wrong, their opinions won’t count as much, and that hurts. Over they years there have been too many arguments based on uninformed opinions in the community, and people who disregards DCI quickly and moves on, even though you cannot understand a new paradigm based on the previous one.

    Sorry, this turned out to be a different post than I originally imagined. 🙂 I will stop ranting and move forward instead. I’m currently developing a large system with DCI in the language Haxe (that compiles to javascript) and it is going quite well. You have helped me to decide that Electron will suit my needs, so thanks again!

  4. Michael Anthony
    August 27, 2015 at 8:43 am

    Both electron and NW.JS are based on CEF (Chromium Embedded Framework) – well to be specific NW.JS is more of a full version of Chromium so if you want to have all of the features that the chrome browser (Blink) offers (Chrome packaged apps and Extensions, etc) then you probably want NW.JS.

    Electron uses a standard CEF based build with Node attached, whereas NW.JS [formally Node-Webkit] which was invented far before Electron/Atom-Shell, decided to go the distance with the concept of Node embedding and fused a custom build of Chromium which combines the NodeJS server process with the rendering loop of Webkit. This shared context design should amount to performance increase if your app involves rendering and/or interaction with data which originates from the Node side of things – which most serious apps do. Electron would require you to use IPC semantics and pipe/stream the data between contexts. This separation is due to the fact that Electron uses an unmodified CEF build (the custom build means rebuilding NW.JS requires expertise and a lot of computing power to build) which results in things being as expected in normal NodeJS programs. This is a good thing for modularity and code re-use outside of Electron. The shared context of NW.JS introduces the need to reference which context you are addressing during programming. I have yet to find a benchmark that establishes which paradigm is faster in action, though I keep meaning to do this myself.

    Microsoft Code is based on CEF and a rumor went around that it was based on Atom-Shell because an old build prototype of it (before its release) had been based on it, this meta-information found it’s way in the non-Atom binary release and thus everyone made this conclusion. Microsoft Code shares nothing in common with Atom or Electron, except that they are both based on the same Chromium runtime.

    If you like endorsements, Node-Webkit began as a project for and with Intel, for the Intel XDK IDE (Cordova/Phonegap based HTML5 authoring environment) which is a very nice visual IDE for interface building and cross platform/mobile development in general. The project however sponsored by Intel was undertaken as a personal project of Roger Wang (the Webkit Ninja) who works at Intel in Japan. This is how Node-Webkit (NW.JS) began it’s life. Now Roger Wang has handed it over to the community and placed it in public repository (he is still the primary maintainer/contributor).

    • Jake
      September 29, 2015 at 1:32 pm

      Do you have a source for this claim that Microsoft Code is not based on Electron? If you open the location of Visual Studio Code, it has an atom.asar file and other remarkably similar files. There are also articles like this claiming to have been told by Microsoft is is using Atom, “A Microsoft spokesperson told us that the technology is indeed based on Electron Shell”

      http://thenextweb.com/apps/2015/04/30/microsofts-cross-platform-visual-studio-code-app-is-based-on-githubs-atom-editor/

    • Arthur Kay
      September 29, 2015 at 1:41 pm

      I do not, I’m just going on what everyone else has reported.

  5. Jake
    September 29, 2015 at 1:50 pm

    I was asking Michael Anthony about this claim 😉

  6. mt
    September 30, 2015 at 12:15 am

    I had the opposite experience regarding filesize —

    with nwjs all you need is the nw.exe (47MB) and your app… while with electron the binaries were 100MB

  7. aa bb
    November 16, 2015 at 5:26 am

    i was pretty excited about electron, but i’m mainly interested in web-scraping and browser testing. electron quickly turned out to be unsuitable as a scraper, as lotsa websites would crash it (e.g. http://hrku01-utility2-beta.herokuapp.com/?modeTest=1)

    nw.js seems to render most external sites fine, so it seems to be the only choice for scraping modern websites (phantomjs is too old and missing modern html features).

  8. Tim
    September 16, 2016 at 7:38 am

    The latest nw.dll is actually 91M on windows. So even a tiny app will automatically hit over 100M in size.

Leave a Reply

Your email address will not be published. Required fields are marked *