Node.js is typically used for servicing web applications, but it has found some other surprising uses as well. There's a fairly sizable robotics (check out Johnny-Five) and drone community around it as well. The programming editor Atom by Github is also a "traditional" desktop app with Node.js at the core.

In my opinion, Node's biggest advantage today is the absolutely massive module ecosystem that has sprung up around it in record time. It's already the biggest, as well as the fastest growing according to http://www.modulecounts.com/ You can find a package for almost everything imaginable, and your typical Node app is made up of dozens of these modules. So take a look at https://www.npmjs.com/, and try searching for whatever field interests you.

PopcornTime is also a NodeJS app.

> The programming editor Atom by Github is also a "traditional" desktop app with Node.js at the core.

Nope, Atom it's based on electron[0] itself which use io.js and Chromium as a core.

[0] https://github.com/atom/electron

It started using Node.js; it switched to io.js in February. I think for the purposes of "What's the use-case for node.js?" node.js and io.js should be considered the same.

I think under this context, a student asking about node’s uses, drawing the distinction between io and node isn’t really relevant, especially since there are plans to merge the two.[1] But thanks for the link, didn’t know about Electron, seems really cool.

http://www.infoq.com/news/2015/05/nodejs-iojs

NodeJs' non-blocking IO makes it a great choice for near real-time communication, like streaming editors, messaging, reacting to high freq events (like metrics). See: http://socket.io, http://en.m.wikipedia.org/wiki/Surespot and https://github.com/etsy/statsd

It is also great when you want to prototype a REST backend, and get it up and running in no time. The simplicity of javascript along with nodejs' module ecosystem make it a breeze (Ruby equivalent would be Sinatra).

What nodejs isn't good at is, parallelism. Concurrency is handled for you for free by the underlying libuv eventing framework. Pseudo-parallelism is achieved using 'clusters' but communication between node processes is costlier than in other languages that support parallelism out of the box.

Read https://news.ycombinator.com/item?id=4305486 for aphyr's excellent commentary on clojure vs nodejs (you can also find Ryan Dahl defending nodejs in a few cases there)

TL;DR: Apps that perform high I/O.

For example, if your app is just getting data from a database and returning it to the user, 90% of your time will be spent:

* Receiving the user's request (Network, IO)

* Fetching something from the DB (Network, IO)

* Returning the data (Network, IO)

That's a good scenario for an event based system like Node.js.

Try not to use node.js if you're CPU-bound: rendering images or PDF, processing sound, etc. If you do need to do something like that and you still want to use node.js you should use a processing queue.

The processing queue is kinda irrelevant, CPU bound tasks require lots of CPUs, and more CPUs if you want a processing queue.

Since Node / nginx are already processing queues it's kinda pointless to add another one.

Thanks!

So, you would use node.js just as a service to process data on the server side and not as a application for the desktop (with a gui)?

Typically Node.js is for high I/O web applications. Thanks to the wonderful asynchronicity of javascript (callbacks "let me know when this is ready/done") it's really wonderful for browser-based programs.

However, there is growing discussion about using Node.js for desktop applications. Please see https://nodesource.com/blog/node-desktop-applications

Node also works well for desktop apps because it's got the run loop.

Desktop apps are insanely high frequency IO apps, basically, its an Input Queue reading the mouse / keyboard / touch screen and a run loop, which is exactly what node is, except node originally envisioned the input queue being web requests. And most desktop apps are single threaded on the UI.

Node.js itself is Google's V8 JavaScript engine (the one in Google Chrome) coupled with a heap of asynchronous non-blocking APIs for IO (http, file system, etc). In that sense, you'd usually use it as a web server (using the builtin http module), although you can pretty much use Node.js just as you'd use any scripting language.

npm[0], Node.js's package manager, is also pretty useful. There's a package to do most things.

Yes, there's some projects that let you create desktop applications using Node.js - what they're doing is using an embedded version of Chrome and pairing it with Node.js. You can then use HTML and CSS to create a user-interface that you can then manipulate with JavaScript. You end up with a fairly bloated distributable application, but the JavaScript code runs on Mac, Windows and Linux.

NodeSchool[1] seems to be the recommended learning resource for Node.js. I've never really used it, but it looks pretty good.

[0] https://www.npmjs.com/ [1] http://nodeschool.io/

Why learn Node.js:

The three most important reasons to use Node.js: it uses JavaScript which you might want to learn already, and second, it has a big ecosystem of modules and frameworks, including by companies like Microsoft and Google, and third, there is more JavaScript code on GitHub than any other language, if you're looking into contributing to open source projects or learning from them.

What you can do with Node.js:

JavaScript was already important as the language of the web browsers. As soon as JavaScript was split off from the web browsers thanks to the Node.js project, people have been writing web servers as well as command-line tools with it. It's also used to create interactive cross-platform native mobile apps and chrome/firefox extensions.

As a bonus, the asynchronous nature of JavaScript and its ubiquity in web browsers as well as web servers has lead to the creation of a wealth of official and unofficial standards and implementations of libraries for creating real-time chat and systems.

If you can do most everything in one language, why not?

Edit: someone already wrote a more technical overview, if you would like one:

https://news.ycombinator.com/item?id=9830207

Don't forget non-blocking I/O.

Thanks, I updated the answer.

I left that out because some commenters mentioned that as the leading feature. But for somebody who's asking what Node.js is used for, I don't think being asynchronous is as important a reason as the fact you're writing JavaScript with great tooling, frameworks, and modules.

As far as coding day-to-day, there are other languages that have better semantics around writing asynchronous code. And it rarely makes a difference for first-time developers until they actually build something and try to scale, and at that point would need to read articles about doing that with Node.js just like they would with Ruby/Rails, Clojure, Go, etc.

I've been use node.js for the server part of my browser multiplayer game. It's been a great decision due to the amount of shared code I have between the client and server.

For example, I share the physics code which is responsible for controlling the simulation that runs on both the server (authoritative) and clients (for predictions).

I no longer have to switch languages which also saves a lot of time!

This sounds pretty interesting, is it open source? Can I check out a demo?

Node.js in itself is a wrapper around V8, the JavaScript engine of Google Chrome. It is used to execute JavaScript on the server for example to implement REST APIs. I would consider Node.js if you implement actual webbased software because you could take advantage of a shared codebase. If you want to display content on the internet there are more comfortable alternatives you could use.

What you are probably looking for is Node-Webkit. It is a toolkit to basically pack a stand alone application with a browser and node.js to create a desktop application.

I personally would recommend to use QT or GTK or some Windows framework if you want to learn how to program a desktop application. No need to deal with the performance problems of web technology and then ship a whole browser with your app if you have to learn something new anyway. In my opinion you should use Node-Webkit only if you know why you use it or if you do not know how to use anything else.

Hi there, thanks for your response.

I programmed some Desktop Apps with Java and C#. And during some hackathons i used python+flask+nginx to implement a Web-Applications with a RestAPI on the backend.

I was just curious for which type of application i can use node.js (since i didn't use javascript on the backend at all). Usually i used PHP, C# or Pyhton for the backend..

Is MS Windows 10 using node.js for their applications (since its possible to develop Node.js apps in Visual Studio Code)?

I do not think, that node.js is involved in the JavaScript apps for Windows. In your place I would test node.js the next time you do something like you did with Flask. If you now C#, I would not recommend to waste time to implement a node-based Windows GUI app.

i will try it! :) thanks!

I think you can develop Windows 10 apps using JavaScript, but as far as I know Node.js isn't involved. I think Microsoft promotes Node.js more so that people use their Azure platform to host Node.js applications.

You can use Node in place of PHP or Python to implement a REST API backend. You can also use it to run scripts the same way you would use Python to do that.

Windows doesn't use node, they have their own JS runtime and a GUI framework that you can script with JS.

I found Node.js to be quite difficult to work with, mostly due to nature of Javascript. Module ecosystem is vast, but each one has an API written in a different style. Combine that with no type-checking and lack of robust IDE auto-completion (Webstorm is quite disappointing at the moment) - and you get a frustrating experience. Oh, and also add asynchronicity into the mix.

Making restful APIs is quite fun with it, though.

As mentioned, i tried Visual Studio Code on OSX. works like a charm.. i would give it a try!

Node is a tool for running Javascript on the server. Your desire to use it will stem entirely upon your desire to write javascript to perform server side tasks.

There are many languages and environments for running code on the server, so I personally have problems finding a niche where Javascript is the obviously better choice for these tasks. In my experience with it so far, it's "fast enough" for IO bound tasks (routing, serving CRUD applications), but if you'd like to perform any form of computation on inputs, you'd probably be better served by a different language ecosystem.

> Node is a tool for running Javascript on the server. Your desire to use it will stem entirely upon your desire to write javascript to perform server side tasks.

Now that's often what people think of Node.js, but that's not really why Node.js is interesting. It's not just "JavaScript on the browser".

Instead, you should think of Node.js more like a JavaScript binding to `libuv`, which is the C library that provides the event-driven I/O core (event loop / queue). (An example for a `libuv` binding in another language, Lua would be `luv` [1].)

Reasons why JavaScript was picked for Node.js: 1) It already dealt with events due to its usage in browsers and 2) a fast existing JIT runtime, V8.

To answer the original question: You might want to use Node.js if your problem is a good fit for the Reactor pattern [2]. For example, scalable network services that "mediate" between a lot of (async) I/O. Not number crunching. Nginx uses the same core concept (Reactor).

[1]: https://github.com/luvit/luv

[2]: https://en.wikipedia.org/wiki/Reactor_pattern

Node is far from the first or only implementation of the reactor pattern in programming languages. There are many other, frequently more mature implementations which exist in most languages.

> Reasons why JavaScript was picked for Node.js: 1) It already dealt with events due to its usage in browsers and 2) a fast existing JIT runtime, V8.

Well, no, the original creator of Node just wanted non-blocking IO (which the frameworks he was using did not support), and (I'm editorializing a bit here) in the grand engineering tradition of re-inventing the wheel, he decided to use Javascript with v8 to create a whole new platform, instead of using an existing platform.

Generally Node has been targeted at server side projects to date (i.e. building web APIs/etc). Stand it up register a listener on a port, and start servicing requests.

Curious: isn't Node single-threaded? How can it scale on a server i.e. on a beefy server with 64 hyperthreads, now can Node capitalize on the available horsepower?

Previously you could launched multiple instance of your program. Today you can use https://nodejs.org/api/cluster.html and leverage all those sweet cores on your server. You can multiprocess but not multithread.

Node includes the cluster module to create child processes that all share the same server port, allowing you to take advantage of all available cores.

You can also run multiple node processes on the same machine (on multiple ports) and use something like NGinx to loadbalance between them. You can use this to get zero-downtime upgrades on a single machine.

Reading all the comments here makes me wonder — Can Python (say, Flask) not be used for real-time communication (SocketIO, etc..) ? What is the difference between that and node.js ?

I am still figuring out a lot of things about Python, and this is something I found very intriguing. What would the differences between an IM app written in Python using Flask and it's nodeJS clone be, to a user?

It could be [1]. IMO, it sounds more like something slapped on top of Flask. You will find similar packages for Django, Pyramid and so on. Tornado feels natural in this sense as it aims to be asynchronous right off the bat.

See also, aiohttp [2] which seems very promising (Python 3.3+). As an aside, I've never seriously considered Python 3 till now after taking a look at aiohttp.

[1] https://flask-socketio.readthedocs.org/en/latest/ [2] http://aiohttp.readthedocs.org/en/stable/web.html

Yes python can, no flask can't.

https://github.com/eventmachine/eventmachine/wiki/EM-vs-Twis...

http://community.eveonline.com/news/dev-blogs/stackless-pyth...

Node.js is one of the few webservers built ground up async.

You can use it for a lot of different application types. It's typically used for web as most web developers already know some Javascript. It's also very lightweight, portable and has a lot of great features that other web languages either don't or don't do as nicely as Node. Asynchronicity for example.

People have also used it for desktop applications, with a few desktop UI library wrappers. Githubs text editor 'Atom' for example.

Node also has a great set of API's for interacting with the system and network utilities, so there's a lot of great tools for networking and automation.

Finally, because Javascript is so lightweight, we're seeing it play a key role in the 'Internet of Things'. Some micro-controllers are even written in JS (see Tessel).

So don't feel as though it's for one thing or another, just have fun with it and explore the language and its potential!

I am not sure it can be called 'very lightweight'. The runtime itself has a large disk footprint, my node_modules is often 100s of MB, and the memory usage is quite heavy too (idle Ghost.org blog takes around ~100MB RSS).

Some of the APIs are not very portable either, such as fs.watch. Many npm libraries implicitly depend on Linux or OS X.

It's convenient though, sure.

Having used Node.js recently for a high volume service my feeling is it is best for lots of network communication.. but not long running or CPU/disk intensive operations. So, we're slowly transitioning to a Go backend with a slim Node.js layer to form the very friendly API while we use some RPC between the Node and Go. In this, Node.js is amazing and--I would guess--hard to beat.

EDIT: Clarify with "CPU/disk intensive operations"

I'm curious about why you say nodejs is not good for long running processes? I currently have a nodejs process running 24/7 pulling a MP3 broadcast stream and haven't had any real difficulties with it, outside anything I would expect with any other language. Granted, the process itself isn't doing anything extreme, just watching certain data in the stream. I'm just curious if there is something serious I haven't encountered yet.

One popular use that I'm not seeing a lot of other folks talk about here is using node to create build tools for web development.

Gulp and Grunt have been very popular as a way of, for instance, watching files and then minifying CSS an JS assets automatically while creating web pages in systems like WordPress that don't have built-in asset pipelines.

Node on desktop is still in early stage, there are some projects but node shines on server side, not only for web/http (mega simple), but also any other application protocols or lower. It's not hard to make socket and do whatever you want + async = win.

On the other hand it's javascript, so :-)

It can be used as a traditional web app or even for microservices. I think the power comes from its asynchronous nature, the ability to write JavaScript backend, and the community and tooling. Anything else?

Node.js is a good option if you’re a front-end web developer who wants to add server-side functionality to a relatively small site.

Node.js is in an interesting position. There is a lot of libraries and new ones are coming out at breakneck speeds. It's also a way for frontend developers to transition to backend tasks. And it gets a lot of mindshare at the moment, with MongoDB and microservices.

But in my opinion a lot of Node.js ecosystem is a lot of mismarketed features. Many developers doing backend services with Node.js actually think that it's the fastest thing available, even though multiple benchmarks, e.g. techempower, shows that it really isn't. And even more people seem to think that it is a way to do simple parallellism, so they won't have to understand threads and locking, which are really complicated stuff. But as many have said here, Node.js does not support threads, or parallelism without running multiple different processes. Which can be fine if you don't have any shared state between your processes. And with no parallelism in process, it is quite easy to actually block the event loop by running anything that is CPU and not IO bound. This can be a loop that is too long, too much math, or even parsing a JSON string without using streams. All of these can block the event loop, which means that no requests are going through that process while one request is parsin a JSON.

And even though there is a lot of libraries and frameworks for it. The quality is often really, really bad. As in invalid MD5 algorithm bad, etc. But there are also some gems such as Bluebird for promises, which makes the callback hell more easier to handle.

You will also face immature debug support, profiling and static analysis. You barely get any refactoring help from your tools, even though IntelliJ IDEA does quite a good job with basic refactoring and debugging. And you will have to spend time with handling odd bugs with no logs showing up on crash, or stuck processes when something has gone really wrong in the code, with no way of knowing (if you don't have DTrace) where the code is stuck.

But there are stuff Node.js seems to excel at. It is really quick for creating a simple REST service, feedback loop is really quick as the services restart almost immediately (at least when you don't use all the latest ES6 transpilers). And if you want to create isomorphic applications, where the server can render a Javascript site on behalf of the browser for the first request, or even successive requests for mobile use, there is no better platform than Node.js. And if you know that you will not do anything that is CPU bound, just IO bound stuff, you can still use any library available. Where for example in Java or Python, you would have to find specific libraries that support your chosen async IO framework.

I would use Node.js between a backend server done in a more robust ecosystem such as JVM, and the browser. Where Node.js gets the data from the backend and does it's magic with isomorphic React for the client.