Building a cross-platform desktop app with NW.js, React and Flux | Hacker News Reader

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

meetfinch.com

126 pointspaynedigital35 comments

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.

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.

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

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

Thanks!

About error reporting in nw.js, it's just like working with chrome (chromium), you see JS errors in: developer tools > console tab.

You could probably send messages to a log instead of the developer tools (might require editing the nw.js source code).

Yeah, I should have been more clear.

Regular JS in the renderer processes showed errors in the console as usual. However, if I tried using one of the NW.js APIs incorrectly in the renderer, or there was any error at all in the main process (which doesn't have devtools) it would just crash.

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

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

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...

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

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.

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.

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.

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

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

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

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.

Try tint: https://github.com/trueinteractions/tint2/

I have to say Tint is a great tool to develop apps with, particularly for binding a node runtime to native (Objective-C and .NET/COM) objects.

I've been using it for the past several months working on two fairly large-scale apps. Thanks Trevor and team.

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)

Most embeddable webviews allow binding additional methods that call into native though. This is how cordova works, in fact. If you're restricting access to local html/js, it shouldnt be any different to nw/electron from a security perspective.

Edit: looks like the tint framework linked above actually isolates the webview from the node runtime. Nice.

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.

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).

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

How do you protect QML/Javascript source code?

You make it part of the Qt resource system[1], which gets it combined with your binary executable.

[1] http://doc.qt.io/qt-5/qtquick-deployment.html#managing-resou...

Thanks. Do you know if the binary packaging is obfuscated to discourage decompilation?

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.

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?

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.

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.

I assume you mean Cordova?

https://cordova.apache.org/

Didn't see much of the Flux stuff explained.

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

Reply on news.ycombinator.com