Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Official NW.js support #28

Closed
TheJaredWilcurt opened this issue Oct 15, 2015 · 7 comments
Closed

Official NW.js support #28

TheJaredWilcurt opened this issue Oct 15, 2015 · 7 comments
Labels

Comments

@TheJaredWilcurt
Copy link

Hey, I'm the creator of UGUI a framework for NW.js. I just tested your project and with a one line change it works fine in NW.js.

Do you have plans to officially support NW.js, or be willing to accept pull requests regarding it. It would take very little effort to set this project up proper for NW.js. And maintenance would require a small amount of changes to your current automated grunt system.

If you've not used it before, they're very similar (except NW.js beats out Electron by a little bit in almost every category). You should try it out, of course you'll need to change your "Electron is the easiest way to build cross-platform desktop applications" line on the website after wards though... since ya know, it's not um... factual.

I'll go now.

@developit
Copy link
Contributor

I think you may have been reading the comparison table incorrectly, as it seems to point to Electron as the better option. Both projects are great, however one would be remiss to overlook the multi-process support built into Electron that is (last I checked) missing from NW.js.

@TheJaredWilcurt
Copy link
Author

To make it easier to understand, I've updated the chart, corrected some items and color coded it to show what I mean:

I removed stuff that was equal, and fixed the file size part and other minor details to make things cleaner.

And "multi-process support" is kinda vague. But in some senses, yes you can. In the sense of multi-process meaning multiple executables running for different windows, extensions, plugins, and child processes, yes it can do that with very little effort. In the sense of a single process using 100% of your multi-core CPU, I'd be surprised if any Chromium based project could do that. Unless you count 3rd party executables that are launched as a child process. But that would be true with anything using Node/IO.js.

The only thing Electron does better is branding and a slight lead in one benchmark. If you remove the branding and just compare "Product A" to "Product B", NW.js is a clear winner. They both have stuff they need to improve on, and right now they are VERY similar, but if you have to say one is better, objectively you can't say it's Electron.

@jprichardson
Copy link

but if you have to say one is better, objectively you can't say it's Electron.

Objectively, you shouldn't say either, as 'better' is a subjective word. But I digress.

  1. Electron now supports Node v4. I'm not at all familiar with NW.js, is it still using io.js?
  2. Why is Chromium better than libchromiumcontent?
  3. Isn't there some JavaScript context issue that a dev needs to worry about when using NW.js?

Thanks for helping to fill in the gaps of my misunderstanding of NW.js.

@developit
Copy link
Contributor

@TheJaredWilcurt You seem quite invested in NW.js, so let's not throw around words like "objective". My point was relating to NW.js re-using the same event loop for both web and Node content, which was the case when heard about it at JSConf in 2012. Your comparison table is lovely, but there are more differences between the two projects than you can attempt to objectively categorize and present in a table. Community aspects, package management and ES6 support are a few that come to mind.

Though I'm not in any way affiliated with Photon, I can tell you it is a CSS library and has nothing to do with Electron itself. However, the author @connors works at Github alongside the people who build Electron, and he chose to promote the project as a great way to kickstart Electron-based apps. Personally, I think that was the right decision considering the rapid pace of adoption the Electron project has been seeing.

@jprichardson Correct, NW is using an older io.js build. I can imagine it is slightly harder to keep up with new Node versions since they have much fewer maintainers.

@connors
Copy link
Owner

connors commented Oct 16, 2015

Yeah we're pretty sold on Electron over here at GitHub 😬... and I'm not really interested in officially supporting NW.js.

@connors connors closed this as completed Oct 16, 2015
@TheJaredWilcurt
Copy link
Author

So, rather than pay for professional software developers, GitHub abuses the open source community to get free work from them. Then refuses to contribute back to the open source community by implementing simple automated systems that benefit everyone, rather than just them directly.

You guys are the devil.

@developit
Copy link
Contributor

Friendly and open competition is actually one of the reasons Open Source is
better then commercial software. I fail to see how Electron benefits only
Github. I don't work for github and I use it every day, both as a platform
and by way of the Atom text editor.

On Fri, Oct 23, 2015, 8:09 AM The Jared Wilcurt notifications@github.com
wrote:

So, rather than pay for professional software developers, GitHub abuses
the open source community to get free work from them. Then refuses to
contribute back to the open source community by implementing simple
automated systems that benefit everyone, rather than just them directly.

You guys are the devil.


Reply to this email directly or view it on GitHub
#28 (comment).

  • Jason

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants