Sharing and reusing JavaScript
While you develop web applications, you will always end up doing the validations for your UI both at the client and server sides, as the client-side validations are required for better UI experience and server-side validations are needed for better security of app. Think about two different languages in action: you will have the same logic implemented in both the server and client side. With Node.js, you can think of sharing the common function between server and client, reducing the code duplication to a large extent.
Ever worked on optimizing the load time for client-side components of your Single-Page Application (SPA) loaded from template engines such as underscore? You would end up thinking about a way we could share the rendering of templates in both server and client at the same time—some call it hybrid templating. Node.js resolves the context of duplication of client templates better than any other server-side technologies, just because we can use the same JS templating framework and the templates both at server and client.
If you are taking this point lightly, the problem it resolves is not just the issue of reusing validations or templates on the server and client. Think about an SPA being built; you will need to implement the subsets of server-side models in the client-side MV* framework also. Now, think about the templates, models, and controller subsets being shared on both client and server. We are solving a higher scenario of code redundancy.
Not just for building web servers!
Node.js is not just to write JavaScript in the server-side. Yes, we have discussed this point earlier. Node.js sets up the environment for the JavaScript code to work anywhere it can be installed. It can be a powerful solution to create command-line tools as well as fully-featured, locally run applications that have nothing to do with the Web or a browser. Grunt.js is a great example of a Node-powered command-line tool that many web developers use daily to automate everyday tasks such as build processes, compiling CoffeeScript, launching Node servers, running tests, and more.
In addition to command-line tools, Node is increasingly popular among the hardware crowd with the Node bots movement. Johnny-Five and Cylon.js are two popular Node libraries that exist to provide a framework to work with robotics. Just search on YouTube for Node robots and you will see a lot of examples. Also, there is a chance that you might be using a text editor developed on Node.js. GitHub's open source editor named Atom, which is hugely popular, is an example.
Real-time web application with Socket.io
One of the important reasons behind the origin of Node.js was to support real-time web applications. Node.js has a couple of frameworks built for real-time web applications, which are hugely popular: Socket.io and sock.js. These frameworks make it very simple to build instant collaboration-based applications such as Google Drive and Mozilla's together.js. Before the introduction of WebSockets in the modern browsers, this was achieved via long polling, which was not a great solution for real-time experience. While WebSockets is a feature that is only supported in modern browsers, Socket.io acts as a framework, which also features seamless fallback implementations for legacy browsers.
Note
If you need to understand more on the use of WebSockets in applications, here's a good resource on MDN that you can explore:
Networking and file IO
In addition to the powerful non-blocking asynchronous nature of Node, it also has very robust networking and filesystem tools available via its core modules. With Node's networking modules, you can create server and client applications that accept network connections and communicate via streams and pipes.
The origin of io.js
As we mentioned earlier in this chapter, io.js is nothing but a fork of Node.js created to be updated with the latest development on both V8 and other developments in the JS community. Joyent was taking care of the releases in Node.js and the process that was followed in taking care of the release management of Node.js lacked an open governance model. It leads to scenarios where the newer developments in V8 as well as the JS community were not incorporated into its releases. For example, if you want to write JavaScript using the latest EcmaScript6 (ES6) features, you will have to run it in the harmony mode. Joyent is surely not to be blamed for this, as they were more concerned about stability of Node.js releases than frequent updates in the stack. This led to the io.js fork, which is kept up to date with the latest JavaScript and V8 updates. So, it's better to keep your eyes on the releases on both Node and io.js to be up to date with the Node.js world.
