NW.js & Electron Compared
If you wish to create a native 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. That is precisely why I created the comparison chart found in this article. Hopefully, it will help you choose the right tool to build your next physical computing project.
An updated version of this comparison has been released in 2016. We encourage you to check it out instead of this one.
At this stage, the chart (and this article) is a work in progress and needs help from the community. As I have used NW.js quite a bit more than Electron, this post probably suffers from my own bias. Please (respectfully) leave your comments, suggestions and corrections to improve it. 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.12.3 | Electron 0.34.1 | |
| Project inception | 2011 | 2014 |
| Sponsor | Intel | GitHub |
| Platform Support | Mac, Linux & Windows | |
| Browser Runtime | Chromium | libchromiumcontent |
| Layout Engine | Blink / WebKit 537 | WebKit 537 |
| JavaScript Engine | V8 | |
| Node.js Engine | io.js v1.2.0 | io.js v? |
| ES6/2015 Support | Yes (all from V8 v4.1) | Yes (all from V8 v4.4) |
| Chrome-Equivalent Version | 41 | 44 |
| Development Model | Open Source | |
| Licensing | MIT License | |
| Entry Point | HTML or JavaScript5 | JavaScript |
| Bare Distribution Size | 75MB – 100MB4 (30MB – 34MB zipped) |
To confirm. Anybody ? |
| Chrome Apps Support | Yes (in beta) | No |
| Support of chrome.* APIs | Yes (in beta) | No |
| Adobe Flash Support | Full NPAPI Plugin | Pepper Plugin |
| Mac App Store Support | Yes | |
| Windows App Store Support | Yes | ? |
| Support for Windows XP | Yes | No |
| Source Code Protection | V8 Snapshot1 | ASAR Archive Support2 |
| Auto-update | Mac/Linux/Win (module) | Mac/Win (thru Squirrel) |
| Kiosk Mode | Partial (Buggy on Mac6) | |
| Windows Installer | Through nw-builder | Yes (external module) |
| html5test.com Score3 | 515 | 520 |
| BrowserMark 2.1 Score3 | 5294 | 5643 |
| Octane 2.0 Score3 | 27619 | 28346 |
| GitHub Trends | ||
| Open Codecs/Containers | Vorbis, Theora, Opus, VP8, VP9, PCM, Ogg, WebM, WAV | |
| Licensed Codecs: MP3, MP4, H.264, AAC | Yes (with some effort) | Yes |
1. This results in a 30% performance hit. It is unclear if it is supported in version 0.13.
2. This is a very weak protection. It’s basically a TAR archive of all the project files.
3. On a MacBook Pro Retina running Mac OS X.5.5 (Yosemite). Higher is better.
4. Unzipped. Depending on platform and architecture. See details in Jared’s comment below.
5. 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.
6. 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.
Additional Comparison Elements
Paradigm
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.
With the upcoming support for Chrome Apps in NW.js version 0.13, it will be possible to use a manifest.json file pointing to a JavaScript file in the manner described in the Chrome Apps documentation.
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 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. I guess this could be positive or negative depending on your needs.
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. It should be noted that NW.js is currently in a transition period because of the integration of the Chrome Apps APIs but everything should fall back into place with the final release of version 0.13.
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.
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. If I get the chance, I will write a follow-up comparison article including Tint 2 . 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.
This 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. 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.
Conclusions
It is hard to draw a final conclusion at this stage but most of the comments received so far seem to favor NW.js. Some of the reasons cited to choose NW.js are: longer track record, overall development philosophy, cross-platform auto-updater and Windows XP support. This conclusion section will definitely need to be refined when more feedback from the community will have been received. Where are the Electron fans? I know you are out there…
87 Comments
nwjs is my choice, although one problem, from my own point of view, right now is the out of the box lack of direct support for mp3, aac and other multi-media formats.
This boils down to a legal issue, I know, but it could and should be corrected going forward.
As of now I have no choice but to release on 12.3 and go no further because of this one issue.
As for Electron, they need more ‘time in the saddle’. I’m not really keen on their choice of direction insofar as overall development philosophy is concerned and doubt I’ll change from using nwjs.
Anton, thanks for your comments. The codecs/demuxers licensing issue is frustrating. At least, it’s possible to get it working in NW.js 0.12.3. In Electron, it is now built-in. The legal impacts of that decision are still unclear to me though.
The products themselves are not subject to a custom license, both are MIT licensed.
Thanks for your comment Martin. You are absolutely right. Since the LICENSE files from both projects’ GitHub repositories had no reference to MIT or other standard licenses, I wrongly assumed they were some sort of custom license. I was wrong. I fixed the chart accordingly.
Thank you for sharing this!
Can you go into more detail about overhead, design mechanism, and APIs involved?
For example, memory usage. I’d really like to understand the specifics about the internals, so I can get a feel for how well the io.js and browser are coupled. And how robust are the frameworks and builtins. Trying to think in terms of sustainability and extensibility.
Great job on the info.
I wish I could share more info. Unfortunately, I’m not involved directly in the projects nor part of the development teams. I, myself, would love to know the answers! You could try posting your questions on each team’s discussion forum:
If somebody answers, I’ll relay the info here. Cheers!
NW.js has had support for starting from a JavaScript file for ages. In the package file, you put in a “node-main” option that points to the script file to run, and you set “window” -> “show” to false.
Moshe, you are so right! I never realized this was available. I guess it’s a good thing I publicly called for help in making sure my data was sound ;-). I’ll change the chart. Thanks!
Electron does indeed have MP3 & MP4/H.264 support. I just tried both.
Also note you don’t need to ship ffmpeg with an Electron app because it’s statically linked as of v0.31.0: https://github.com/atom/electron/releases/tag/v0.31.0
Josh,
Thanks for pointing that out. Obviously, you are right (I tried it myself too). I was thrown off by comments in the forum regarding mp3/mp4. However, since ffmpeg requires in its license that applications developped with it be GPL-licensed, I’m unclear as to what that means for Electron-developed applications. It’s probably okay but… who knows?
Ffmpeg is LGPL unless you build it with
--enable-gpland/or--enable-nonfree.If you built it with those flags, you then have AAC/X264 codec support. So from this point of view, NW.js is safely to use for property product, and it is have flexibility to load the patent protected codecs in libffmpegsumo.so (you could find it in any google chrome browser folder)Thanks for your input Halton. However, I’m not sure I understand your point. If ffmpeg is built with
--enable-gpland I use it in my application, my understanding is that my app must be GPL-licensed as well.Good tip! I posted a little something in the nw.js thread you started.
As I figure things out, I’ll send it your way!
Excellent! Thanks.
Hi Jean,
One thing that I realised is that you focused more on the internals of each, but I believe the biggest selling point of electron is it’s out of the box features that you didn’t mentioned, on what their site they call as “The hard parts made easy”, which includes: Automatic updates, Crash reporting, Windows installers…
I’ve used a lot of NW.js in past (when it was node-webkit) and automatic updates and windows installers can be a big deal.
That said I never really used Electron that much to see how easy is to use those features, but as a consumer those are important points that I would take in consideration when using then.
Wilker,
You make a very good point! I must admit I’m not too familiar with those features myself. I’ll do some digging and add them to the chart.
Thanks!
I did a bit of research and it turns out that NW.js might have better auto-update support than Electron. There is a module for NW.js called node-webkit-updater that supports auto-update on Mac, Linux and Windows. I have not tried it myself but judging from the 300+ stars on GitHub, I’m guessing some people have. Electron natively supports auto-update on Mac. For Windows, you will have to rely on Squirrel. The grunt-electron-installer module will let you build a Windows installer using Squirrel.
Support for Windows installers on NW.js remains unclear to me. It might be possible to create one with nw-builder (that remains to be confirmed).
nw-builder outputs several files (an exe, several dlls and i18n files).
The solution I have found is to create an installer from nw-builder’s output, using nsis :
http://nsis.sourceforge.net/Main_Pagenw-builder was super easy
And one more thing about Electron: it doesn’t support XP nor Win2003. I know that market share of XP is about 4-5% but NW.js supports and it may hurt in corporate segment, where XP is still alive
Andrew,
Are you sure about Windows XP support? I thought Chrome/Chromium itself dropped support for Windows XP earlier this year. Do you have a spec or an article I could link to? I could add it to the post.
Thanks!
Hi,
indeed, Windows XP is not supported by Electron : https://github.com/atom/electron/issues/691
But nw.js does support Windows XP : https://github.com/nwjs/nw.js/issues/2932
I have tried nw.js on Windows XP and it does work.
Chrome/Chromium dropped support for Windows XP, but that simply means that if there’s a security breach or a critical bug, it won’t be fixed.
Thanks. I added it to the comparison chart.
Electron also does not support Mac OS X Lion (10.7). I found this out by accident when my laptop was broken and I had to use my old Mac Pro. I am not 100% certain it supports Mac OS X Mountain Lion (10.8) and I could find no documentation on their website or github repo as to what operating systems they officially support.
You know, Enyo (http://enyojs.com/get-enyo/) is another option for complete cross-platform/browser coverage, as well. It is in flux at the moment, switching to a require-style system in ver 2.6. You should check it out.
sugardave,
Enyo looks like an interesting project. However, unless I’m mistaken, it is not in the same category as Electron and NW.js. As far as I can tell, Enyo is simply a webapp framework that can be packaged. It does not seem to provide the native APIs (filesystem, processes and devices access) offered by NW.js and Electron (at least not beyond Cordova and Chrome Apps). Am I wrong?
Ah, you are correct, I am guilty of skimming your article on the airplane. There is no native hardware/sensor access for platforms outside of cordova (or the like) by design. Oops 😀
Awesome chart. I would like to know how the projects compare with respect to the following:
Do they both start a web server to deliver content to libChrome?
Or, do they operate without an internal web server in the loop?
Josh,
There is no web server involved. The pages are parsed just as if you had opened them locally. What’s exciting is that even though no webserver is involved, you still get full access to the local machine through the Node.js APIs which are directly available in your DOM JavaScript code.
Cheers!
Great post, thanks.
It’s always nice to hear that! 🙂
Hi,
That comparison is very very helpful! Thank you so much.
But, what about Tint? (https://github.com/trueinteractions/tint2)
It would be great if you could compare it with both NW.js and Electron.
Dear Daniel,
I decided to omit Tint from my comparison because the first release was basically node-webkit with extra bells and whistles. From what I read, it seems that version 2 will be quite different. I guess we will have to wait for an official release before it can objectively be compared. I’d be willing to write a follow-up article when version 2 is available.
Cheers!
P.S. Meanwhile, I will add an “other contenders” section to the article and mention Tint.
Hi Jean-Philippe,
Tint 2 is actually finished (and has been for a year now), you can download the latest versions at https://github.com/trueinteractions/tint2/releases
You can also read the getting started guides here:
Happy to answer any questions you might have.
Cheers,
Trevor
Trevor,
If it’s been finished for a year, is there a reason why the project’s web page ) still invites visitors to submit their email to be notified of its release? Are you being extra, super careful with your testing?
In any case, would you be willing to fill in the above chart with the relevant info from Tint 2? This would allow me to kick start a new version of this article.
Cheers!
Hi Jean-Philippe,
The website trueinteractions.com is a placeholder for a commercially supported version of Tint we have been building.
The correct URL for the free, (as in, however the hell you wish to use it) is at
The github repo and download point for Tint2 is https://github.com/trueinteractions/tint2/releases
I’ll put a comparison together, but its no-where near apples-to-apples comparison so it makes it a bit misleading to imply its another chromium-in-a-shell competitor (for an explanation, see:
I’m a big fan of NW.js and love this post. I’ve spent the last year creating a framework for it that I thought I’d mention here.
NW.js is already the faster and easier alternative to Electron/Bracket-Shell/Tint, but with my framework (UGUI) it becomes ridiculously simple.
Here’s a video I made yesterday using it. In less than 30 minutes I created a desktop app using only HTML (and editing the package.json file for stuff like window height and app name). Though UGUI also has a rich JS API built in as well for common tasks you’d need in an NW.js app.
It’s a free, open source, framework. Hope it can help people bootstrap their projects.
Thanks for posting it. I’ll check it out! Would you have some specifics on why you prefer NW.js over the others ?
I updated your chart to be a lil more accurate, removing the stuff that was equal:
I kinda guessed on the file sizes. Here’s some more accurate numbers below. You can see, when zipped an NW.js app is between 30 and 35MB.
When unzipped it’s around 75-100MB. This requires removing extra stuff that isn’t needed for distribution of most apps. Which you should do anyways when you go to distribute. Distributed sizes with an app:
Distributed sizes without an app, (bare minimum needed for NW.js to run)
Thanks for putting this together. This is worthwhile information. Adding the colors to the chart definitely makes NW.js stand out but I’m not sure it’s 100% accurate. Let’s look at some of the items:
Thoughts ?
This is what the web needs is more direct comparisons in a succinct format.
With all the biased comparison articles out there, where people try to sell their preference, it’s hard to know what’s what.
Now I know the REAL differences between the 2, and it’s nothing to do with stats or performance or capabilities, as all of that is largely the same between the two. It seems that it’s all about the dev methodology: top down vs bottom up.
As I said, I cannot completely dismiss my own bias but I tried to be fair and I’m glad you agree. Your comment regarding the difference in methodology is interesting. I’m not sure I agree with it being the ONLY significant difference but you are right to point out that this is a fundamental difference. To me, choosing a platform is also about choosing a development team, a community, a track record, etc.
Well its Electron all the way FTW! Size matters! http://www.akawebdesign.com/2015/05/06/electron-vs-nwjs/
Some people report NW.js as producing the smaller sized apps (including someone in the comments of the article you cited) while others report the exact opposite. Jared reported in the comments above that a bare-minimum NW.js app is between 75Mb and 97Mb (unzipped, depending on the platform and architecture). What is the bare-minimum size for an Electron app ?
With NW.js i have to pack my app in myapp.nw everytime i make changes to test it. That is a pain. With electron , i just do “electron .” and it runs the app. No need to pack it. I used NW.js before Electron , so the article i linked to changed my mind to use Electron instead. For big size of NW.js build it needs alot of extra stuff added with it like besides the NW executable, nw.pak and such. Maybe its cause it uses full Chrome features and Electron does not that it is a bigger build. But i like NW.js at first, just having to repack app to myapp.nw everytime i want to test my app is very sad.
Nevermind, i discovered one can do “nw .” to run an app. Just NW.js need more coding than Electron to work with native api’s
Do you have data to back that claim? I am trying hard to keep this post objective and would prefer to avoid unsubstantiated opinions.
Easy there Mr Red Bull 🙂 . I am new to this. Sure builds are big on both platforms. Your bias is a good thing. NW.js has been around longer and is the best way to go for now. I just wish they could fix the loading issues on Windows. It takes around 3 minutes with NW.js and Linux its a few seconds. All good in the end.
I’m sorry if I came off to harsh. However, comparing applications is always a delicate operation. I want this article to be a fact-based tool that people can use to make the right decision.
Having said that, I am surprised to hear that it would take 3 minutes to start NW.js on Windows. However, I must admit that I mostly used NW.js for interactive installations on Mac. I have not had that much experience using it on Windows. Are others having the same issue with the loading time ?
Hi,
It’s just a guess but loading time may have to do with the choice to zip package the app on the windows platform. In that configuration the zip is temporary unpacked to the temp folder before launching which can be quite long if big.
In that case it’s best not to pack the data for quicker startup.
You should make a mention of flash plugin support. Electron/chromium doesn’t support NPAPI while NW supports NPAPI. It makes a difference for applications which rely on NPAPI based flash player plugin. Pepper Flash plugin has more restrictions and reduced support for some protocol(s).
This is probably going to change in v0.13. However, until then, the chart has been updated. Thanks for pointing it out.
Regarding use of the GPL license:
Not necessarily, dual license GPL + commercial is very powerful license choice.
(refer to Neo4J for instance http://neo4j.com/licensing/ and Richard Stallman on freedom https://www.youtube.com/watch?v=Ag1AKIl_2GM)
You are right. I rewrote this part to reflect that releasing under the GPL may, or may not, be suitable for everybody.
Lame and x264 are GPLed, so if ffmpeg linked against them than it should be GPL. However, Lame and x264 are only needed for encoding mp3 and h264, not decoding, because ffmpeg has buildin mp3 h264 decoders, which are LGPLed.
You can confirm this by run
./configure --list-decodersin FFmpeg source tree, and note thatlibxxxare third-party decoders, others are buildin.See also [mp3](
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegaudiodec_fixed.c) (link down)and [h264](
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c)(link down).I believe Electron only uses ffmpeg for decoding mp3 and h264, not encoding, so license is not a problem.
The real problem is the patents. h264 is still patented. Google Chrome ships with a h264 decoder because it would pay the fee if any; Chromium don’t because Google wouldn’t pay for redistibuters/users of it. I think Electron’s redistibuters/users still have to deal with patent issues of h264 themselves.
Thanks for this info. Hopefully, it will help some people out there.
I really appreciate this comparison of nw.js and electron! I am just trying to figure out which one to use for a project. I found it especially disturbing that electron statically links to a version of the ffmpeg library that is compiled with options that make it GPL. My understanding is that if that were true, electron could not legally be considered MIT and must be licensed under GPL itself and thus everything made with it must be licensed this way. I wanted to know if that was really true, and give the electron folks a chance to address the issue if it was really an issue. So I posted this issue on the electron project: https://github.com/atom/electron/issues/3449
They are claiming electron and chromium (as used by electron?) are not using versions of the ffmpeg library compiled with GPL codecs. I don’t have enough knowledge of or experience with electron or chromium to know if that is really true or not. Unfortunately they not only closed, but also locked that issue, so I can’t inquire further about that through the issue. Even if they are correct, locking the issue and advising to only bring up further issues about this inside the Chromium project feels a bit like sweeping things under the rug. I specifically chose the word “feels” because if they are correct, that is not what they are doing, but by locking it and not allowing further discussion, they seem to be encouraging people to mistrust them rather than have a chance to get their concerns fully addressed, which feels like sweeping things under the rug. I found this related information:
https://github.com/atom/electron/issues/633
https://github.com/atom/libchromiumcontent/pull/69
I don’t know if further developments have happened since then, but it sounds like electron is setup to use proprietary codecs if they are available, but does not include them itself.
Thanks for your research. I rewrote this part of my article after going through your links and performing some more research on my end.
The LICENSE.md file of the Chromium project is fairly clear: Chromium (and I guess libchromiumcontent) use a version of FFmpeg that is LGPL. So, as long as you do not compile in other options (with –enable-gpl or –enable-nonfree) you should be good to go with both Electron and NW.js.
Hi Jean,
Very nice article, I was looking for something related to use node on desktop development and found it. I used to develop desktop app in java and I am interested in desktop development again. It seems that desktop development is also converging to HTML5, is that true? I am interested in developing with one of that tools but looking at their latest versions (0.35.0 for electron and 0.12.3 for nw.js), seems that their are not mature enough to trust in a comercial project. Could you (or someone else) share your experience with one of that tools?
Thank you, and sorry for my not very good english 🙂
As you can see from the links below, both NW.js and Electron have already been used many times for commercial products:
That does not necessarily mean that desktop development is converging towards HTML but it demonstrates that its definitely possible to use the web stack for application development.
Thanks Jean,
I think I will give NW.js a try.
Hi All,
And how do we test NW.js applications, i mean what are the test automation tools available for Automating NW.js applications
Various JavaScript testing tools will work right out of the box. For instance, you can use a combination of the
mochaandchrome-remote-interfacemodules to do that. Check out this article for more details:http://blog.yanivkessler.com/2015/03/21/automate-nwjs-ui-testing/
Sounds like a pretty good write-up. However, it *is* possible to close an Electron app for good when the last window is closed, just move this line of code outside of the darwin function: https://github.com/IdeasNeverCease/Aries/blob/master/main.js#L20-L27
I was building a web browser in node-webkit first, and was able to use iframes to do so. I stopped development for a few months and when I came back to it, I decided to use Electron, based upon the good things I was hearing about it (and, Slack is built with it). The most difficult part of my web browser was getting the iframes to cooperate, but I did that with ease using webviews.
Thanks for chiming in. The reason for using iframes was so you could have a single window with multiple tabs, is that it? Because, otherwise, you could have opened multiple windows.
Could you update the chart with the current versions please? 😀
Once NW.js v0.13 is out of beta, I will probably create a new article with updated data.
Cheers!
Piece of shit… why to use that fucking colors?
You never get noticed about colorblind? Mtf.
Well, actually, I did test my theme for the most common types of color blindness and did not find any contrast issues. Instead of being an anonymous ass, perhaps you could tell me what the actual problem is so I can fix it and help others.
By the way, you do know I’m not getting paid to do all this, right? *sigh*
Not the original poster but from this image – http://i.imgur.com/K6YeWGf.png I find that the first box is a bit hard to read (still readable) while the second box with the white is easier. For reference, I suffer from Protanomaly.
Thanks for the great article and cheers.
I made the chart’s text black. Hopefully, my color blind friends will find it easier to read.
Unfortunately NW is now seriously behind still stuck with Chromium v41!
I wish the Chromium engine was an external bin file or something so you can choose which version to marry into your app instead of waiting for one guy to post a NW update.
And what happens if this one guy decides to abandon NW? We’ll all be left in limbo!
I’m getting very concerned about this lately…
NW.js has been under heavy development over the past few months because of a very beneficial change in architecture. As of today, version 0.13-beta7 of NW.js uses Chromium 48. I have been waiting for the final release of 0.13 before updating the chart above.
Regarding your second point, you have to know that Chromium is very tightly integrated into NW.js. It is not a simple matter of picking one executable over another. Chromium has to be recompiled specifically for NW.js with each release.
Regarding your last point, you should know that both Electron and NW.js have a core group of between 5 and 10 regular contributors. In both cases, most of the code is being written by one person which (I’m guessing here) is paid by their respective sponsor (Intel for NW.js and GitHub for Electron). Since these are open source projects, if these guys decided to abandon them, the community could pick up where they left off. I’m not saying this is ideal but it’s certainly better than a private company going under that leaves its users with no alternatives…
My 2 cents.
You cannot take any of those recent v13s seriously as they’re all full of bugs!
The last good working version was v12.2 with v12.3 being a bloated version with unnecessary Mac App Store crap that doesn’t interest me in the slightest.
Ever since they decided to go down a different path they’ve gone downhill because it’s almost 8 months with no proper working version in sight and that’s a tale-tell sign that they’re in trouble and/or have abandoned it.
Eight months in the programming world is a very long time and Chromium has since moved on by another 10 releases!
At the very least they should release NW 12.4 with the latest Chromium engine… they owe it to all those who have invested so much in their language.
Of course they’re full of bugs. They are beta versions! Also, judging by the high level of activity on GitHub, it doesn’t look abandoned at all. If anything, it looks like it’s undergoing a major bout of development (which it is).
Being an open source project, I don’t think they (whoever that is) owe anything to anybody. Users are in debt here, not the other way around.
I find people often have a strange conception of open source software. They tend to feel entitled as if they had actually invested money in the the free software they were given. If you feel the pace of development is not fast enough, you can always get involved.
Here is the roadmap for version 0.13.
Great comparison.
I have been using Electron for about 6 months and have been very pleased with it so far. I wanted to pass on a couple things.
1. Someone mentioned it does not support NPAPI, which is correct. However, you can develop native node addons (https://nodejs.org/api/addons.html).
2. For those interested, there is a great boilerplate (https://github.com/szwacz/electron-boilerplate) for Electron that makes it really easy to get started writing a cross platform application from scratch–including installers. It is a great place to start a new application.
Did anyone got PDF views working in any of these frameworks? Also printing from the same?
It looks like nw.js v0.13 has been released. We’d love to see an updated article based on the new release! Thanks in advance.
Consider it done!
http://tangiblejs.com/posts/nw-js-and-electron-compared-2016-edition
Comment welcome!
I do not know whether it’s just me or if perhaps everybody else experiencing issues with
your blog. It looks like some of the text within your content are running off the screen. Can somebody else please provide feedback and let me know
if this is happening to them as well? This could be a problem with my internet
browser because I’ve had this happen before. Thanks
You are the first to report this issue. Which platform/browser are you using ?
Those contemplating moving to NW should be warned.
The idea was great and was going ok at the beginning but has since evolved thus:
* It is extremely buggy and there’s no end to the problems in sight.
* With every release they just keep moving the goal posts.
* They keep adding more and more useless “features” resulting in bloated exe’s.
* For every 5 bugs they claim to “fix” it seems another 10 are introduced.
* The documentation is horrendous (bad/weird English), seriously lacking in coverage and detail, and all over the place on the Internet with version confusions.
* It is NOT modularized…. meaning it’ll lump *everything* in your app whether you’re calling it or not.
* Settings in the “package.json” (meant to kick-start crucial app options) are mostly ignored. Very little; if anything, is mentioned in the docs about abandoned/ignored options.
* The project is mismanaged and handled in a very amateur way with no clear vision or direction other than a “let’s cover everything” attitude and achieving nothing. The only thing that seems guaranteed for NW is that the bloating and bugs will continue exponentially.
Conclusion:
If you make your living out of web apps I strongly advise you to steer clear from NW to avoid disappointment.
I wouldn’t even recommend it for amateurs doing small apps because the result is too bloated to make a small app worth distributing. In fact there’s no such thing as a “small app” with NW when a “hello world” is 100mb!
Best way to describe NW these days… a bizarre monstrosity that’s going nowhere but pulling a lot of suckers. 🙁
Thanks for taking the time to comment. What I pick up from you comment is that you think NW.js is bloated, buggy and poorly documented.
Regarding bloat, do you have an alternative to suggest? Unless I’m mistaken, Electron’s bare size is just about the same as NW.js in the (120-130MB range).
Regarding the documentation, I believe the introduction of the new documentation section is helping a lot ( http://docs.nwjs.io/en/latest/. It might not be perfect but I find it to be pretty decent.
Finally, regarding the bugs, my perspective is that NW.js has done a much better job since v0.13 (which introduced a new architecture).
I’m not saying everything is perfect but calling it a “bizarre monstrosity” is a bit of an overstatement, don’t you think?
By the way, I invite you to take a look at the updated version of this article for data that is more in line with what’s available today: http://tangiblejs.com/posts/nw-js-and-electron-compared-2016-edition
In hindsight, if I could have my time back (almost 3 years) that I had spent (read wasted) with NW, I probably would’ve mastered C++!
I’m sure I would’ve learned enough of the 3GL to correctly incorporate Chromium to fire up my HTML as well as having full disk I/O that actually works instead of that unstructured junk of a language they call node.js that NW relies on.
At the time I thought I was taking a shortcut by going with Node Webkit for web-apps but now I know that I had done exactly the opposite.
I hope that answers your question.
Hi jean i hope you can help me, I make a simple application and bag it with node webkit, I did it with node web kit 32- bit v0.3.7 in my windows operating system 64, the application ran but did not sound, then I returned to create it with node web kit 64-bit v0.12.3 and if sounded in my windows 64, my question is that then 32 does not run well on an operating system 64, i mean to run with out problems i should create 32 to windows with nodeweb kit 32-bit and the 64 with the node web kit 64, Thank you?
Pepe,
I’m not sure I fully understand your question but, obviously, you should use the version that matches the target architecture. You can always repost your question with more details to the NW.js discussion group.
Cheers!
Nice writing ! I am thankful for the information – Does someone know if I could possibly locate a sample MS DOM 300 version to edit ?