NW.js is a runtime for building desktop applications using Web technologies.
Like WebViews for iOS/Android, NW.js leverages the latest in web technologies (Chromium and io.js) to provide a complete platform for building fully-featured desktop applications using the same technologies used for the Web.
Web applications are the past, present, and future, but there are some cases where it’s not recommended to host an application on a remote server. With the arrival of HTML5, we now have low-level functionality added to modern browsers, like the ability to read and write files to a computer’s file system.
That opens up the possibility to create offline Single Page Applications (SPAs) using a web browser as a platform.
That presents some interesting possibilities, such as the ability to deploy your application on multiple operating systems.
Let me provide a little insight into the history of the NW.js project. The node-webkit project (its original name) was created at Intel and open-sourced in 2011 in an attempt to solve the problems encountered in creating SPA offline applications.
The project provides developers with a WebKit browser that has been extended with the the ability to control user interface elements, normally off-limits. The browser’s security configuration is relaxed, because it assumes that the application code you’re running is trusted. And, most interestingly, the browser integrates Node.js, allowing developers to leverage a wide array of functionality other than what HTML5 APIs provide.
The rebranding of the node-webkit project into NW.js was done because the webkit browser was replaced by Chromium and instead of Node.js the project uses io.js.
Chromium is an open-source browser project that was started in the development of Chrome and Chrome OS. You can look at Chromium as the development release and Chrome as the stable release, hence the histories of the two are intertwined.
io.js is an open-source project that began as a fork of Joyent’s Node.js. Its aim is to have more frequent releases and faster adoption of the latest developments of the V8 runtime. It also remains compatible with the Node Package Manager (npm) ecosystem.
NW.js can be installed on all major platforms, Windows, OS X and Linux. It supports both x32 and x64 platforms. Installing it is a breeze. You can find a downloads section on the project’s page which supplies a number of archives containing ready-to-run NW.js binaries with software libraries they depend on.
Once you have the appropriate archive you’ll need to locate the NW.js binary. For Windows the binary name is nw.exe, for Linux is nw and for OS X, which comes packaged in an application bundle, the binary is located inside in the Contents/MacOS folder and is called nwjs (/path/to/nwjs.app/Contents/MacOS/nwjs).
Installing is as easy as placing the extracted folder in the place of your choosing.
If you are used to coding classic web apps, you might be a bit baffled as it’s possible within a script tag to access Node.js APIs.
An advantage with going desktop instead of a browser is that you can do much more than what a simple web app allows you to do, thus making it easier to sell your application. For example, there are already games on Steam that are just web apps, but using NW to run “natively” on the desktop.
You do not need a SDK or full blown IDE, just use your usual tools. Write HTML and JS files as you would normally do but consider NW as the browser. Then package and distribute your app and the user won’t notice or care that they are using, in essence, a browser.
From a distribution perspective there are two ways you can do that. You can either have everything packaged inside the app (that includes NW.js ~100MB) or trust the users to install NW.js on their machines. I personally, don’t think that asking or trusting the users to have NW.js properly installed on their local machines is an option, as easy as installing NW.js can be. It would present a too higher risk for the entire functioning of the app to consider this as a viable option, even though having another ~100MB added to the app is not the ideal scenario either.
NW.js is not the only solution out there; we see more and more alternatives rolling out as time passes by. Some of the more popular ones are TiDeSDK, Sencha Desktop Manager or Electron (previously named Atom Shell).
TiDeSDK is a more complete solution that aims to bring under one roof all platforms to create desktop applications.
Sencha Desktop Manager is included with Sencha Complete and in essence aims to do the same thing as TiDeSDK with one big difference: it only supports Windows and Mac OS X.
Electron is the platform over which the Atom text editor was built. It solves the same problems as NW.js but it does it somewhat differently. It doesn’t integrate Chromium, but instead uses libchromiumcontent to access Chromium’s Content API.
Frameworks like NW.js have been out there for a while now but only recently began to grow in popularity. We are seeing more and more apps built using NW.js or other similar frameworks (Wunderlist, Atom, Brackets, etc) that look and feel like native apps. I believe the decisive moment that made these types of frameworks viable was when NodeJS was blended in, giving app developers the possibility to mimic basically all of the native features so far forbidden for a classic web app.