javascript node.js web-applications

How to decide when to use Node.js?


I am new to this kind of stuff, but lately I’ve been hearing a lot about how good Node.js is. Considering how much I love working with jQuery and JavaScript in general, I can’t help but wonder how to decide when to use Node.js. The web application I have in mind is something like Bitly – takes some content, archives it.

From all the homework I have been doing in the last few days, I obtained the following information. Node.js

  • is a command-line tool that can be run as a regular web server and lets one run JavaScript programs
  • utilizes the great V8 JavaScript engine
  • is very good when you need to do several things at the same time
  • is event-based so all the wonderful Ajax-like stuff can be done on the server side
  • lets us share code between the browser and the backend
  • lets us talk with MySQL

Some of the sources that I have come across are:

Considering that Node.js can be run almost out-of-the-box on Amazon’s EC2 instances, I am trying to understand what type of problems require Node.js as opposed to any of the mighty kings out there like PHP, Python and Ruby. I understand that it really depends on the expertise one has on a language, but my question falls more into the general category of: When to use a particular framework and what type of problems is it particularly suited for?



You did a great job of summarizing what’s awesome about Node.js. My feeling is that Node.js is especially suited for applications where you’d like to maintain a persistent connection from the browser back to the server. Using a technique known as “long-polling”, you can write an application that sends updates to the user in real time. Doing long polling on many of the web’s giants, like Ruby on Rails or Django, would create immense load on the server, because each active client eats up one server process. This situation amounts to a tarpit attack. When you use something like Node.js, the server has no need of maintaining separate threads for each open connection.

This means you can create a browser-based chat application in Node.js that takes almost no system resources to serve a great many clients. Any time you want to do this sort of long-polling, Node.js is a great option.

It’s worth mentioning that Ruby and Python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that Node.js does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with JSON native to both the client and the server is pretty nifty.

I look forward to reading other answers here, this is a fantastic question.

It’s worth pointing out that Node.js is also great for situations in which you’ll be reusing a lot of code across the client/server gap. The Meteor framework makes this really easy, and a lot of folks are suggesting this might be the future of web development. I can say from experience that it’s a whole lot of fun to write code in Meteor, and a big part of this is spending less time thinking about how you’re going to restructure your data, so the code that runs in the browser can easily manipulate it and pass it back.

Here’s an article on Pyramid and long-polling, which turns out to be very easy to set up with a little help from gevent: TicTacToe and Long Polling with Pyramid.


  • 12

    Yes, I think it is very important to think that ‘node.js is especially suited for applications that require persistent connection from the browser back to the server. – such as chat programs, or interactive games’ If one is just building an application that does not necessarily need user/server communication, developing with other frameworks would be just fine and will take much less time.

    Sep 27, 2011 at 7:03

  • 12

    Why use long polling? What happened to the future and sockets?

    Feb 11, 2016 at 7:46

  • 1

    My short answer is background process. Request and response (including rest API) all can be achieved with any other language and server. So for those who are thinking to convert their web projects in node. Think again its the same thing! Use the node as a background process like reading emails with imap, image processing, uploading files to cloud, or any lengthy or never ending processes which are mostly event oriented…

    – Vikas

    Mar 20, 2016 at 12:27


I believe Node.js is best suited for real-time applications: online games, collaboration tools, chat rooms, or anything where what one user (or robot? or sensor?) does with the application needs to be seen by other users immediately, without a page refresh.

I should also mention that Socket.IO in combination with Node.js will reduce your real-time latency even further than what is possible with long polling. Socket.IO will fall back to long polling as a worst case scenario, and instead use web sockets or even Flash if they are available.

But I should also mention that just about any situation where the code might block due to threads can be better addressed with Node.js. Or any situation where you need the application to be event-driven.

Also, Ryan Dahl said in a talk that I once attended that the Node.js benchmarks closely rival Nginx for regular old HTTP requests. So if we build with Node.js, we can serve our normal resources quite effectively, and when we need the event-driven stuff, it’s ready to handle it.

Plus it’s all JavaScript all the time. Lingua Franca on the whole stack.


  • 17

    Just an observation from someone switching between .Net and Node, The different languages for different areas of the system help a great deal when context-switching. When I’m looking at Javascript, I’m working in the Client, C# means the App Server, SQL = database. Working in Javascript throughout, I’ve found myself confusing the layers, or simply taking longer to context-switch. This is likely an artifact of working on the .NET stack all day and Noding at night, but it does make a difference.

    Sep 8, 2015 at 15:29

  • 1

    Just the other day I was thinking about how I could go about assigning different colours to my different .js files somehow. Green for client-side, blue for server-side. I keep getting “lost” myself.

    – AJB

    Dec 30, 2015 at 18:46


Reasons to use NodeJS:

  • It runs Javascript, so you can use the same language on server and client, and even share some code between them (e.g. for form validation, or to render views at either end.)

  • The single-threaded event-driven system is fast even when handling lots of requests at once, and also simple, compared to traditional multi-threaded Java or ROR frameworks.

  • The ever-growing pool of packages accessible through NPM, including client and server-side libraries/modules, as well as command-line tools for web development. Most of these are conveniently hosted on github, where sometimes you can report an issue and find it fixed within hours! It’s nice to have everything under one roof, with standardized issue reporting and easy forking.

  • It has become the defacto standard environment in which to run Javascript-related tools and other web-related tools, including task runners, minifiers, beautifiers, linters, preprocessors, bundlers and analytics processors.

  • It seems quite suitable for prototyping, agile development and rapid product iteration.

Reasons not to use NodeJS:

  • It runs Javascript, which has no compile-time type checking. For large, complex safety-critical systems, or projects including collaboration between different organizations, a language which encourages contractual interfaces and provides static type checking may save you some debugging time (and explosions) in the long run. (Although the JVM is stuck with null, so please use Haskell for your nuclear reactors.)

  • Added to that, many of the packages in NPM are a little raw, and still under rapid development. Some libraries for older frameworks have undergone a decade of testing and bugfixing, and are very stable by now. has no mechanism to rate packages, which has lead to a proliferation of packages doing more or less the same thing, out of which a large percentage are no longer maintained.

  • Nested callback hell. (Of course there are 20 different solutions to this…)

  • The ever-growing pool of packages can make one NodeJS project appear radically different from the next. There is a large diversity in implementations due to the huge number of options available (e.g. Express/Sails.js/Meteor/Derby). This can sometimes make it harder for a new developer to jump in on a Node project. Contrast that with a Rails developer joining an existing project: he should be able to get familiar with the app pretty quickly, because all Rails apps are encouraged to use a similar structure.

  • Dealing with files can be a bit of a pain. Things that are trivial in other languages, like reading a line from a text file, are weird enough to do with Node.js that there’s a StackOverflow question on that with 80+ upvotes. There’s no simple way to read one record at a time from a CSV file. Etc.

I love NodeJS, it is fast and wild and fun, but I am concerned it has little interest in provable-correctness. Let’s hope we can eventually merge the best of both worlds. I am eager to see what will replace Node in the future… 🙂


  • 1

    @nane Yes I do think they can address that issue, however you must then limit yourself to using only libraries written in typesafe languages, or accept that not all of your codebase is statically typed. But one argument goes: since you should write good tests for your code regardless of the language, then your confidence level should be equal even for dynamically typed code. If we accept that argument, then the advantages of strong typing are reduced to assisting developing/debugging time, provability, and optimization.

    Aug 23, 2015 at 16:46

  • 1

    @kervin, I agree some benchmarks would be great, but I was disappointed with what I could find online. Some have argued that .NET performance is comparable to Node’s, but that it is crucial what you are actually doing. Node might be great at delivering little messages with many concurrent connections, but not so great for heavy mathematical calculations. A good performance comparison would need to test a variety of situations.

    Aug 23, 2015 at 16:59

  • 2

    @joeytwiddle wouldn’t things like Typescript help Node.js when it comes to handling larger complex programs and static typechecking?

    Sep 3, 2015 at 6:33

  • 2

    @joeytwiddle for what it is worth, you can use to determine whether or not an npm package is still maintained (as the majority are on github). In addition, npm search and npm show will show you the date of the last release of a package.

    – Dan

    Nov 3, 2015 at 12:38

  • 3

    By comparing rails to node you’re confusing a platform to a framework. Rails is a framework for Ruby just like Sails and meteor are frameworks for Javascript.

    – BonsaiOak

    Feb 26, 2016 at 15:10