Building a cross-platform desktop app with NW.js, React and Flux

Building a cross-platform desktop app with NW.js, React and Flux(meetfinch.com)

126 points by paynedigital 10 years ago | 35 comments

SingAlong 10 years ago |

Was recently looking for information on building desktop apps with Electron or NW.js. Found a few useful links regarding source code protection. In short: Documented method is v8 snapshots. They are compiled code, run slower and are not cross platform.

* Using v8 snapshots - https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source...

* Electron thread about source code protection - https://github.com/atom/electron/issues/3041

The second link has a lot of comments with useful information. One of them mentions that v8 snapshot format is documented and also that the actual code is shipped with the snapshot for future optimizations. nw.js just removes the sourcecode from the snapshot.

I'm curious if there is any reliable means of source code protection for Electron or NW.js apps.

tommoor 10 years ago |

Long time user/supporter of both NW and Electron, It's worth noting that Electron has surpassed NW in almost every way at this point. If you want to program against clean node-style API's then Electron is the one to choose.

ronjouch 10 years ago | |

Good to have this kind of feedback from someone who used both. Could you expand the comparison on a few key points?

johnthedebs 10 years ago | | |

I'm not OP, but I've also used both and recently switched a production app from NW.js to Electron. I'm extremely happy with the decision to switch.

Benefits of Electron:

* Much more active development, more frequent releases, more quickly addressed bugs (this is huge)

* More active ecosystem

* Lower level API that requires you to perhaps do a bit more work to achieve the same cross-platform behavior but gives more control and fewer weird issues

* Much better documentation

* Much better error reporting. It may have just been me, but when I had a JS error in NW.js, the process would simply crash with no feedback whatsoever (which as you can imagine is infuriating). I opened a couple issues about it and never got any help or feedback. Electron pops up a dialog with a stack trace.

Edit:

* Another major difference is that NW.js uses a shared global object for communicating between the main process and renderer (BrowserWindow) processes. Electron uses evented message passing using an `ipc` (inter-process communication) module that makes for more robust code.

* Besides being lower-level, the API is just (IMO) a lot better/more powerful in general

discohead 10 years ago | |

You say in "almost" every way, are there any ways in particular where you feel that NW.js is superior to Electron?

wildpeaks 10 years ago |

I hope React Native will expand to desktop eventually, native controlled by javascript is the best of both worlds.

mhd 10 years ago |

So, what's the resident memory usage? That was part of why e.g. Java and Flex weren't that well received, and browser-based solutions didn't fare that well either.

Okay enough for something enterprise-y, but once your fancy new IRC/Slack/Twitter client takes up a gig of RAM...

gnrlbzik 10 years ago | |

My Gitter im instance been running for past 2-3 weeks and it only consumes 100 megs. It runs inside nwjs

rtpg 10 years ago |

I reallllly want someone to repackage how NW.js works to be able to ship just the app files, and have NW.js work like the JVM. Super tired of having 20 different instances of webkit

Very full guide though, down to release.

pinum 10 years ago | |

I for one do not. Desktop/laptop storage drives are huge now, RAM is plentiful, internet connections are fast. Time spent debugging horrific deranged multiple JVM setup nightmares, however, is as expensive as ever.

paulddraper 10 years ago | | |

https://en.wikipedia.org/wiki/Wirth%27s_law

mynegation 10 years ago | | |

Maybe someone should explore the concept of "docker for JVMs/WebKits". Or - to be more precise - aufs for multiple versions of big runtime. Although I suspect that disk space savings may not be that good, and that will not solve RAM problem either.

seanwilson 10 years ago | |

Wouldn't this be like installing Chrome then and installing Chrome apps?

chrisdevereux 10 years ago | |

Or even better, use the platform's native webview.

kitsunesoba 10 years ago | | |

Yes please! I’m not a fan of wrapper apps, but for the ones that I have no choice in using (Slack for instance) it’d be great if they used the copy of WebKit included with OS X, preferably through WKWebView. While web engines are always going to be mammoths, at least OS X bundled webkit is specifically optimized for the OS and tends to be easier on the battery than Chromium-based stuff.

rtpg 10 years ago | | |

The thing NW.js offers is access to node.js libs through JavaScript. This isn't available through the native webview (for good reason! Very much a security risk)

mwcampbell 10 years ago |

The section about crossing the uncanny valley reminds me of this old rant about Microsoft Foundation Classes:

https://www.relisoft.com/resource/libs.html

The author likens MFC to a specialized Lego set for building a pirate ship, whereas the Win32 API is a general Lego set. I think the analogy is much stronger if one replaces MFC with web tech in a native wrapper, and Win32 with any OS native toolkit.

blub 10 years ago |

Really nice article, thorough and shows the pluses and minuses of this solution.

I noticed that they discarded the C++ option due to being unfamiliar with the language, but there might be an alternative: Qt's QML is a declarative language that's designed for easily creating interactive UIs and I think it's a great fit for a custom UI like the one in the article. The interesting part - one can embed and include JavaScript in a QML file (http://doc.qt.io/qt-5/qtqml-index.html).

kidproquo 10 years ago | |

This. For Tasktopus[1], I started with Electron, had a decent prototype in 2 weeks[2]. Then hit some issues - very rudimentary print support, large binary size, hard to protect source code. Decided to switch to Qt/QML. Very pleased with the result.

[1]https://gumroad.com/l/ADWm/tasktopus [2]http://imgur.com/gallery/NZzEFKX

walterbell 10 years ago | | |

How do you protect QML/Javascript source code?

rhengles 10 years ago |

I'd much rather use Java, and SWT, which implements native widgets than ship a browser without toolbars. They can even leverage their JS code with Nashorn or Rhino.

mwcampbell 10 years ago | |

SWT is pretty good, and the fact that it uses native widgets makes it great for accessibility. Creating a well-behaved menu bar on OS X was tricky in my experience though. Also, how would you package the app? Ship the full Oracle JRE, or use something more lightweight like Avian?

rhengles 10 years ago | | |

I work as a web dev, I'm only a hobbyist wrt desktop programming, despite having worked on a small commercial app in Delphi. The toy apps I've built with SWT were tested only on Windows. I didn't even know about Avian - nice reference. But if I had to ship an app, i'd leave it up to the user to install JRE, on the installation instructions.

z3t4 10 years ago |

I think the intended package method is to get the user to first install nw.js then just give them the app files.

nw.js is backwards compatible, so if your app works now, it will probably work in future versions too!

If you do not care about Windows 7 you could use cardova instead.

strictnein 10 years ago | |

I assume you mean Cordova?

https://cordova.apache.org/

sktrdie 10 years ago |

Didn't see much of the Flux stuff explained.

TranquilMarmot 10 years ago | |

From the article,

> This isn’t a tutorial on using either library [React and Flux] but if you’d like to see one by all means let us know.

"let us know" is a link that directs you to https://meetfinch.com/contact