Electron vs nwjs (part 2)

A few months ago I wrote a blog post titled Electron vs nwjs which has gathered quite a bit of traffic. I have spent the past five months building sizable apps with both projects (to be clear: different apps) and I feel as though I have some excellent clarity into the things I both like and dislike about Electron and nwjs — as well as my current approach to building apps in each.

Note: everything that follows is completely anecdotal. I’m just some guy who builds software and rants about it on The Internet; trust my advice and experience at your own peril.

OSS Activity

As I mentioned in my prior post, Electron is still my preferred project. One of the things I really like about Electron is the pace at which new releases are coming — there have been 10 releases since the end of September! The project is quite stable despite that pace, and bugs appear to get fixed quickly. The dev team is also very active on the GitHub issues.

By comparison, nwjs only has two releases since I wrote my original post. Some rather important (IMO) bugs have yet to be fixed in v0.12.x.

Release activity may not always be a sign for “the better choice”, but considering that GitHub maintains Electron I think it’s a solid reason to lean that direction right now.

The nwjs docs on GitHub also seem to be fairly outdated. They regularly refer to “node-webkit”, which hasn’t been the project’s name in nearly a year.

Winner: Electron

“Securing” Source Code

At a high level, Electron and nwjs are exactly the same thing. They both enable you to package a web application (plus some Node.js back-end stuff) into a standalone desktop application. There are some nuances between the two with regards to how “context” is derived, the general APIs that govern windows, menus, etc… but for the most part, the only significant difference between the two projects boils down to one feature: the ability (or lack thereof) to “secure” your source code.

nwjs offers the ability to protect JavaScript source code with a v8 snapshot. Electron does not.

I have already gotten into an argument with the Electron contributors about this topic. In my opinion, this single feature is the only reason why developers will choose nwjs rather than Electron… yet they seem pretty disinterested in pursuing the idea.

Their argument has merit – the v8 snapshot isn’t true source code security, it’s just well-obfuscated code — and it comes with a sizable performance hit. But if the only alternative is to leave source code completely clear, developers would much rather choose the illusion of security for proprietary applications. I think it’s a no-brainer to add that feature; they disagree. For now.

Winner: nwjs

Build Process: Grunt

For my own projects I frequently use Grunt to do of the local build things — it’s really easy to setup, and it really helps create “production” versions of your applications. Both Electron and nwjs have very helpful Grunt packages available on npm and GitHub.

The ones I use for Electron:

  • grunt-exec: Running command-line tasks is incredibly useful
  • grunt-contrib-uglify and grunt-scram: Remember how Electron doesn’t have a v8 snapshot or any mechanism to secure your source code? A combination of UglifyJS and scrambling the results will at least deter most people from spying on your souce code. (THIS IS NOT SECURITY!)
  • grunt-contrib-copy: Helpful for copying files/folders around the file system
  • grunt-string-replace: Helpful for updating build numbers and other things
  • grunt-electron: The real meat of the build process. Specify the desired name/version/platform you need for a production app. Even includes the .asar compression for your app folder.

The ones I use for nwjs:

  • grunt-exec: Running command-line tasks is incredibly useful (same as I did in Electron). Specifically,
  • grunt-contrib-copy: Helpful for copying files/folders around the file system (same as I did in Electron)
  • grunt-contrib-concat: Helpful for many things, but most notably if you need to concatenate many JS files before you “secure” them in a v8 snapshot
  • grunt-nw-builder: Similar to “grunt-electron” in that it produces the desired name/version/platform for a production build.

For example, to create the v8 snapshot you might do the following:

grunt.initConfig({
    exec : {
        nwjc : {
            cwd : 'build/nwjc',
            cmd : 'nwjc app.js app.bin'
        }
    },

    concat : {
        nwjc : {
            dest : 'build/nwjc/app.js',
            src  : [
                'app/js/fileA.js',
                'app/js/fileB.js',
                'app/js/fileC.js'
            ]
        }
    },

    nwjs : {
        options : {
            platforms : [ 'win32', 'win64', 'osx64' ],
            buildDir  : 'build/platforms',
            version   : '0.12.3',
            //macIcns : '',
            //winIco  : ''
        },
        src     : [ 'build/production/**/*' ]
    }
});

grunt.loadNpmTasks('grunt-exec');
grunt.loadNpmTasks('grunt-contrib-concat');
grunt.loadNpmTasks('grunt-nw-builder');

grunt.registerTask('default', [
    'concat',
    'exec',
    'nwjs'
]);

The last step here (“nwjs” target) assumes some other things are in my build/production folder, but you get the idea.

My Grunt setup for Electron is nearly identical, minus some nuances in things needed for the individual projects.

Winner: tie

Startup Time

While I didn’t try to specifically time the startup process in both of my apps, I will say that Electron started noticeably faster on OSX and Windows — both locally during development, as well as my production builds.

Oddly enough, my Electron app is considerably more complex than my nwjs app. The nwjs app did use a v8 snapshot (which has a known performance hit), but even running the app locally without the v8 snapshot it seems much slower to startup.

Winner: Electron

What is your Experience?

Remember: I’m just some guy who builds software and rants about it on The Internet. Your mileage may vary significantly with these projects, but barring the need to “secure” your source code I would choose Electron every time.

If you have built apps with either of these projects I would love to hear more about your thoughts and experiences!

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.

17 comments for “Electron vs nwjs (part 2)

  1. Christian Dube
    November 2, 2015 at 8:58 pm

    Thanks Arthur. I’ll give Electron a try. I am using nw.js in my current project but it hasn’t shown much progress (beside yesterday’s beta release) and the startup time is terrible.

  2. Roger Levy
    January 8, 2016 at 6:46 pm

    Are there any source compatibility issues between the two? What if I want to develop in Visual Studio Code / Electron and then deploy to a Chrome Packaged App with NJ.ws? Does that represent a major effort on my part?

    • Arthur Kay
      January 8, 2016 at 8:22 pm

      For the most part I haven’t run into too many issues. However, if you’re using any of the native APIs for Electron or nwjs, clearly those will break if you switch between the two.

  3. Dillybob
    February 5, 2016 at 5:50 pm

    “Also, imagine if the Path of Exile developer’s at Grinding Gear Games knew you could just view the source of their client side game and how it interacts with a game engine that had hundred of thousand’s of man hours dedicated to it? Their inventory system, skill tree and everything just simply available to view by browsing the directory? **That’s not right**. That’s how I feel about my game, there should be some type of protection. Especially when you have a dedicated team working on these features and then for someone to just steal the client side code by browsing a folder directory? I feel like that’s just wrong to be honest.

    Not to sound rude, but people need to realize that WebGL (especially with Pixi v4 (Developer at Blizzard is working on this, and other engines) are really the future of 2d and even 3d game development. And Javascript is not going anywhere soon and will only continue grow. The beginning of web game development has just begun and you will most likely see more game developer’s flock over to nw.js or electron to package their game.

    With that said, I hope the developers here really hear me out and take my post seriously. I’m not trying to be braggadocious in any way, I just want to let the developers here know that we do care about our code.”

    I also posted another post and they deleted it. Hilarious.

    They truly don’t give a shit.

  4. Dillybob
    February 5, 2016 at 5:50 pm

    Btw, I posted that on the github tracker.

  5. Dillybob
    February 5, 2016 at 5:56 pm

    Here is a picture before he deletes it:

    https://i.gyazo.com/d87ca5ad3e08ace26cd60cf031c160e2.png

  6. Dillybob
    February 5, 2016 at 6:08 pm

    Alright, so my argument was this:

    I have a game with over 50,000 lines of code, written in Javascript using Phaser. Gameserver has well over 100,000 lines of code. It’s an ARPG similar to Path of Exile and D2. My argument is our team having to spend thousand’s of man hours into programming and designing the architecture of the client side code and everything; we should have an ability to at-least somehow protect our client side code. This was the gist of my initial post, but it was much longer. The paul guy: https://github.com/paulcbetts delete’s the post (I didn’t know he did as I was typing out what I posted above in the comment section here), then I tried to submit that post and it wouldn’t let me so I refreshed and boom, both comments delete. The guy is a disgrace and obviously doesn’t recognize the need for source protection. Very sad!

    • Arthur Kay
      February 5, 2016 at 9:58 pm

      FWIW I had my two cents on that GitHub issue six months ago as well, and I long-ago gave up on seeing this feature added. I’m frustrated that the Electron team doesn’t want to address that feature, and quite honestly I feel like their responses have been dismissive at best — and closer to mean-spirited at worst.

      Having said that, I think calling Paul “a disgrace” is going way too far. He’s been very helpful on other issues, and he’s clearly working hard on a great product. At the end of the day Electron is an OSS project and GitHub literally doesn’t owe us anything, no matter how important/valuable a feature might be to us/anyone.

      In my opinion, the Electron team does recognize the need for source code protection — they’re simply choosing to not address it. However they have not adequately (IMO) explained the rationale behind that decision, and I think that is what angers a lot of people. More to the point, I don’t think the Electron team has effectively communicated what the project’s roadmap actually is — making decisions like this infuriating.

      The whole issue boils down to trust. As developers, we need to trust that GitHub is going to (1) continue development on this great project, while also (2) adding critical features we (the greater community of users) want. From what I’ve seen so far, neither Electron nor NW.JS have completely gained my trust on these two points…

  7. Dillybob
    February 17, 2016 at 12:11 am

    Arthur, The reason I think disgrace was used because he deleted my post which was just me giving them an applicable example of why source code protection would be a good idea. I spent a lot of time writing that post and for him to simply delete it is just uncalled for. I think my usage of that word is justified, but I can see your point maybe it was a bit too far. But honestly, after seeing someone on their team reply to my post with even more text then I posted and it wasn’t deleted? It just shows as you said, some type of ‘dismissiveness’ is happening in the interim.

    In any event, I’m done with that entire fiasco and I’m just not going to participate in their github if that’s how they are going to act. Their loss not mine (although, Electron is pretty bug-free at the moment, not really a loss to them, but whatever :))

  8. February 23, 2016 at 7:43 pm

    Nice write up Arthur.

    On your point of slow startup time for NW.js, the culprit is in the packaging. NW.js basically zips everything up and merges it into the executable for distribution. When the user launches the app, it extracts the files…. every time the user opens the app. Size/complexity of the code base isn’t the problem, the extraction process is. This is why it takes less time to open an app while developing it compared to a packaged release. I worked around this using a custom installer, but it was a pain.

    I have since switched to Electron, but I also wish Github would pay a little more attention to code security for proprietary codebases.

  9. March 11, 2016 at 11:07 am

    Thanks, Arthur. But there is one more thing to mention: Extension respectively plugin support.

    – NWJS supports NPAPI plugins[1] and nw13 will support Chrome extensions[2]. However, it’s unclear if it supports normal plugins (see my question in [2])
    – Electron does not support plugins or extensions[3]

    [1] https://github.com/nwjs/nw.js/wiki/third-party-browser-plugins
    [2] https://github.com/nwjs/nw.js/issues/3815
    [3] https://github.com/atom/electron/issues/1498

    • Arthur Kay
      March 11, 2016 at 2:42 pm

      Interesting, I wasn’t aware that NWJS supported *Chrome* extensions in any flavor… very cool! That would definitely be a tip in the direction of NWJS for projects that required that feature.

      Thanks for pointing that out!

  10. George
    April 16, 2016 at 7:38 am

    Hello Arthur, thank you for the brilliant article(s)! I am traditionally a backend developer, but will be developing an application in nwjs/electron soon. I wanted to ask you about your IDEs/workflow for both of these frameworks.

    I am wondering if there is an IDE that allows you to debug nwjs/electron applications, instead of using the Chrome Developer Tools from the running instance itself. I am more of a 1-button-compile-launch-and-debug-from-your-IDE kind of guy. Do you work the same way or use tools (like the command line) external to your IDE?

    Thank you very much in advance!

    • Arthur Kay
      April 18, 2016 at 12:30 pm

      George — it’s a bit tricky because there are two runtimes (contexts) in an nwjs/electron application: the “main” process (background/server stuff), and the “renderer” process (the traditional web/UI thread).

      I have hooked WebStorm up to debug the “main” process in an Electron app, which is pretty easy to do. Presumably the same could be done with nwjs. The setup is basically to create a “run configuration” for Node.js — I’m sure that most full IDEs have similar features.

      However both electron and nwjs allow you to have multiple “renderer” processes open at any time, so I don’t know how you would be able to use the IDE to debug those — not that you’d want to anyhow, because Chrome Developer Tools is much more useful for the UI stuff (HTML, CSS, etc).

  11. Scott Hatfield
    April 21, 2016 at 3:45 pm

    Hi, Arthur. Thanks for your informative post. I’m a complete newbie to NW.js/Electron, and haven’t done any more than simple experimentation, but I’m fascinated by the possibilities.

    Couldn’t code protection be somewhat accomplished by obfuscation of the JavaScript using Google Closure Compiler or something? Granted, that wouldn’t protect any true intellectual property, but it would make it mighty inconvenient to steal the code outright. I don’t develop games, but I can’t imagine what secret algorithms or interactions with a game engine I would worry about my competitors stealing. I don’t mean to downplay anyone’s concerns – I’m just genuinely ignorant on the matter.

    Thanks,
    Scott

    • Arthur Kay
      April 21, 2016 at 3:51 pm

      Yes, that’s very true. You can (and indeed I have) obfuscate the JS code to make it inconvenient for hackers… personally I feel like most hackers wouldn’t care enough about my apps to actually bother in the first place.

      Having said that, some apps have highly sensitive data embedded within their code. Not necessarily algorithms — more like logic for validating a product license, or payment submission, or things like that.

  12. wildloop
    April 21, 2017 at 11:32 am

    Electron vs NW.js (April’17).
    – Stackoverflow questions Electron: 2,630 vs NW.js: 269 (http://stackoverflow.com/questions/tagged/electron http://stackoverflow.com/questions/tagged/nw.js),
    – Github pull requests Electron: 102 vs NW.js: 6 (https://github.com/electron/electron/pulse/monthly https://github.com/nwjs/nw.js/pulse/monthly),
    – apps built on Electron https://electron.atom.io/apps/ vs NW.js https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js
    – and finally Google Trends: https://trends.google.com/trends/explore?q=nwjs,electron%20js
    Electron seems to be better choice.

Leave a Reply

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