What are the functional differences between NW.js, Brackets-Shell and Electron?

Question

Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).

The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:

• Platform support; operating systems, dependencies, etc.
• Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
• Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
• Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
• Architecture; in particular the architectural differences that affect daily usage as a developer.
• Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
• ... and so on.

What are the objective, technical differences that matter when making a choice between them as an application developer?

Solution 1

I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.

Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.

https://github.com/adobe/brackets-shell#overview

Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.

I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.

These things are true for all three of them platforms - runs on Windows, Mac, and Linux language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.

The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.

Solution 2

I've been playing with Atom-Shell over the last few days, and I am loving it so far.

The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).

I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.

---

Bullet Points:

• Platform support: Windows, Linux, Mac OSX (More Info Here)
• Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
• Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
• Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
• Architecture: Covered in the other points, but in general its very smooth.

---

Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.

My opinion of the platform remains positive. It's pretty awesome.

On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.

I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.

Solution 3

Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:

• Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
• Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
• Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
• enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
• kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
• supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
• support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0

There is much more to see in the wiki including Menu, Tray, etc.

Solution 4

I've been working with brackets-shell for some time now, here are some of my findings:

• brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
• The project is backed by Adobe and has a lot of activity

• Documentation could be better

• platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.

• feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
• native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
• extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
• architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).

Solution 5

One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.

NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.

NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.

If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.

View more solutions

Comments

[stefan]

Have you had any luck looking at the differences in the meantime? Might do some digging this weekend

[Sven Slootweg]

@stefan Not yet, no :/ I've experimented a little with node-webkit in a practical sense, but haven't gotten beyond that yet. Haven't gotten around to looking for formal documentation of the differences...

[sepulchered]

Well, here is main differences between node-webkit and atom-shell outlined by atom-shell team, github.com/atom/atom-shell/blob/master/docs/development/….

[Timothy C. Quinn]

How about the Elephant in the Room: Debugging. I have been using nw.js and found that debugging is quite lacking when using the linux platform to develop. To develop large applications, debugging is a critical feature IMO. Can we add debugging to the list of desirable features to talk to?

[Sven Slootweg]

@JavaScriptDude Thanks, I've added that to the list.

[John W. Clark]

@JavaScriptDude debugging in NW.js is pretty much like any js debugging. The only trick is to make sure that the package.json file for your app has "window": { "toolbar":true } , once that is done there is a button to open the debugging console/

[Timothy C. Quinn]

@John. Thanks, I am aware of the various ways to debug nw.js and others. What I am speaking to is when comparing the various chromium based frameworks, its important to take into consideration how they vary in with debugging capabilities. There is the potential that they vary slightly in implementation and have the opportunity to optimize the debugging experience for the developers. IMO, debugging is one of the most important features when developing complex software.

[Sven Slootweg]

Could you elaborate on whether there's any difference with regards to MP4 playback in brackets-shell and atom-shell? It's not clear from your answer whether this is a quirk in most WebKit distributions, or just in node-webkit.

[John W. Clark]

MP4 playback being a problem is a webkit issue. You have to remember that webkit is really chromium at heart, and unless the AV tech is open and free they don't support it out of the box. The standard answer is to replace/rebuild ffmpegsumo. Replacing it with one from your current Chrome install seems to work fairly well.

[Sven Slootweg]

Can you elaborate on the differences with node-webkit in particular? As far as I can tell, all (most?) of these points are offered by node-webkit as well, but I'm not sure if there might be something I'm missing.

[Ehtesh Choudhury]

It just happens to be that Brackets is built on bracket-shell and Atom is built on atom-shell, but you can use any editor or IDE of choice to create code with them. I think what the OP wants is more on the technical differences between the 3. It would be sweet to see something like TodoMVC across the 3 runtime-like environments.

[John W. Clark]

@SvenSlootweg the codec support is more about the libraries used with the webkit you are using. All three are using Chromium as the webkit base, so they all have the same codec issues, and they can be resolved the same way.

[John W. Clark]

The thing that got me to stay away from Brackes-shell was their own overview. github.com/adobe/brackets-shell "Note: The brackets-shell is only maintained for use by the Brackets project. Although some people have definitely had success using it as an app shell for other projects, we don't provide any official support for that and we haven't done a ton of work to make the app shell easily reusable. Many people will likely find it easier to use a project like node-webkit, which is more generic by design."

[Munish Kapoor]

hi luke is it possible to update atom-shell application it self ...?

[Luke Chavers]

@SvenSlootweg Sorry I missed your comment from a few months ago; Unfortunately I am not well versed with node-webkit and could not compare the two effectively. But I did read this StrongLoop article, which at least indicates that Atom-Shell has broke new ground. :\

[Luke Chavers]

@MunishKapoor For development? You can download the latest release.. I more or less just rename the old atom directory and replace it with the new. They may have some snazzy process like "npm update" -- but I have not investigated it. For updating your app+atom shell on the client, I do not think they address that directly (at all) and presumably expect that you'll use an installer or other external platform for that. I did find this article in their docs interesting, though.

[user1541413]

Use Case? - I have been playing with "Chrome Apps", in particular, Webview. The Use Case is building "API like behavior" for web sites that do not offer an API to their data and their XHR data is normally hard to access. The workflow via Chrome Apps is a bit clunky, so I am looking at alternatives like Atom-Shell.

[Moonwalker]

@LukeChavers Is there something similar to v8 snapshot for atom-shell?

[Luke Chavers]

@Moonwalker Yes, it uses an app called "Asar" for packaging. ( see: "Application Packaging" ). I also just found this Node-Webkit/Atom-Shell comparison.

[Timothy C. Quinn]

+1 on Kiosk mode Roger. I can see that being a feature that I will use in the future. Hopefully debugging capabilities improve so I can stay on nw.js however right now I am seriously considering switching over to Atom Electron for a while to test the waters. I've found the debugging in nw.js a bit wanting.

[Sven Slootweg]

I'm a bit concerned about the inclusion of "protecting JS source" there - it's in the same class as DRM, in the sense that it doesn't work. It only "protects" from those you didn't need to "protect" against to begin with. Doesn't seem like something that should be advertised as a feature to me.

[Roger Wang]

It's not like DRM for Web -- JS programmers should be able to do anything as C++ programmers can do, including compiling the source code to machine code, when they develop native applications.

[Roger Wang]

@JavaScriptDude do you mean the devtools? In the next version (0.13) the experience will almost be the same as in Chrome browser.

[Timothy C. Quinn]

@Roger. Sorry for the delayed response. Yes, devtools. I found that the following limitations were there, some of which are likely in the devtools itself: 1) No debugging of new windows launched. 2) Remote debugging never worked. 3) Inability to recall breakpoints, watch variables and sources opened (every time restart app, all settings are cleared) 4) (the real biggie) Inability to debug code loaded with require().

[Sven Slootweg]

@RogerWang Compiling source code into machine code is a byproduct of how compiled languages work. It is not intended to "protect" source code. My objection against that bulletpoint is purely because of the suggestion that it "protects" your code in any way (it doesn't).

[Karol Klepacki]

Chrome didn't stop support after MS did it - support was extended to the end of 2015 - chrome.blogspot.com/2015/04/…

[Michael Kruglos]

electron (atom-shell) doesn't run on RHEL 6.6 and below, and the source code cannot be compiled on those distros.

[RationalDev likes GoFundMonica]

Just a note that GitHub say Electron was always meant to be more than just a shell for a text editor, "When we got started, our goal wasn't just to support the needs of a text editor. We also wanted to create a straightforward framework that would allow people to use web technologies to build cross-platform desktop apps with all of the native trimmings."

[Vishal]

Can you please take a look at this question: stackoverflow.com/questions/37797780/…

[evalarezo]

On the other hand, Electron comes with Mac App Store-compatible builds and even supports ARM builds

[Jaredcheeda]

You can use nw-builder to create the MAS versions. There are arm builds for NW.js as well.