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