Please tell me if:

  • Node.js will make our site faster!
  • Node.js will consume fewer server resources, we can save money!
  • Node.js will make us more productive!
  • Node.js means we can share client and server side JavaScript code.

To clarify, we're rewriting a frontend server, which will talk to our existing Ruby on Rails application as an API. Meanwhile, we'll refactor our Ruby on Rails application into services.

More details on the existing architecture:

  • Memcached for HTML partials caching
  • Redis for session, and some structured data caching
  • MySQL single master, multiple slaves
    • There's one large table that accepts a lot of writes (imagine a poll)
    • Otherwise mostly reads.
  • MongoDB for some metadata
  • Ruby on Rails 3.0
  • nginx and Unicorn
  • 33
    sheesh, all these hipster languages. A well written php application will scale easily, the traditional tools work, don't let those hipsters tell you otherwise.
    – Darknight
    Apr 17, 2013 at 8:54
  • 5
    The question should be more along the lines of "Will the improvements save enough money to the business to make it worthwhile?" It might save money over 5 years but rewriting is expensive and time-consuming - unless your code is a horrible horrible mess I think your managers are being mad
    – Mikey C
    Apr 17, 2013 at 9:48
  • 4
    If rewrites are being considered, you could also consider moving your front-end to client-side javascript, which means you wouldn't have a dynamic front-end server anymore, just static files. Apr 17, 2013 at 10:06
  • 11
    @Darknight bear in mind that at one point PHP was the hipster language, and that people showing it could be deployed in successful products promoted its adoption—while the Perl web developers were sniggering at the PHP hipsters.
    – user4051
    Apr 17, 2013 at 12:49
  • 9
    I am very surprised no one has brought up the Joel Spolsky article Things you should never do. I'm not saying all rewrites are bad, but I agree with @MikeyC that they should be approached with extreme caution. Apr 17, 2013 at 13:30

2 Answers 2


Most of the questions you ask are not answerable without context, and are more or less moot given management has already made the choice for you... unless you are asking 'should I quit and find a new job in the face of all this change?'

If your going to tough it out I recommend you read this this post on the topic: How To Survive a Ground-Up Rewrite Without Losing Your Sanity.

I recently started down the path of rewriting a bit of server logic in node.js. The main reason was it is currently written in .NET and we are wanting to migrate away from MS environments down the track.

My experiences so far have been positive, you will have an initial learning curve with all the non-blocking-ness of it but once you get past that it's actually quite fun to code in.. I know, FUN!

It does have a dark side though, every man and his dog who has done some front end development with JavaScript - and that would be every front end developer I hope - gets a little excited when you mention that node.js is 'server side javascript' however that does not mean front end developers will have the experience required to write good server side apps.

For one thing you have consider is that a fatal error will bring down the whole app due to it's non threaded nature, so the stakes are a little higher and you have to explicitly check and catch everything.

For those who have done both front and back - and enjoy both - not having to switch mental contexts from front end to back end languages is a real bonus that I think will ultimately boost productivity in our team down the track.

  • "For one thing you have consider is that a fatal error will bring down the whole app due to it's non threaded nature, so the stakes are a little higher and you have to explicitly check and catch everything" - That would be my worry.
    – tentimes
    Apr 24, 2013 at 7:15
  • Yes, my main point with that statement was that front end only developers are typically not particularly fussy when it comes to exception handling. Come on, it's almost 2017 already !
    – dave.zap
    Dec 19, 2016 at 18:13

Well, I don't think that rewriting the application was a good idea unless it was performing poorly. To answer your questions:

  1. Node.js is not magic. Your application has huge amount of users, so there is no way to be certain that it will make it faster.

  2. Well, yes, Node.js does in fact consume fewer server resources. So not only can you save money on resources, but you can also do more with the existing ones. This is mostly because of single-threaded nature of Node.js. There is no overhead of additional threads.

  3. Again Node.js is not magic. Having said that, there might be some truth in that. Node.js has a very active community that has created hundreds of modules for every possible task. So it is quite probable that most of the work has been done for you. You just need to fit the pieces together.

  4. Theoretically, yes. Since Node.js is JavaScript, you can share code between the client and server. But I don't know exactly what it is that will be shared. I have not written any piece of code that was reusable on a client. Things that we do on the server usually has nothing to do with the client. More important to me is the lack of context switch. I find it easier to code on both client and server in a single language.

Since Node.js is single-threaded, unless explicitly configured to do so, it can't take advantage of multiple CPUs.

Take a look at the comments too. They provide some good insight into the workings of Node.js.

  • 16
    Less resources because of a single thread? What do you think those extra threads would be doing?
    – Joe
    Apr 17, 2013 at 10:04
  • @Joe as far as I understand they will add up.In node js it is a best practice to dispose off a request as quickly as possible.Either by completing it in one go.Or by resuming it next time.To be honest node js is the only technology that I have made production applications for.So I may not be the best person to compare it with other server side technologies.Which is why I have refrained from making comparisons and just put what I think I know of node js in my answer. Apr 17, 2013 at 10:14
  • 7
    Yes, a single thread certainly limits resource use, because the server can only do one thing at once on the event loop. It also limits server use, because it can only do one thing at once. It is very important to quote features (single-threaded) and upsides and downsides rather than just upsides. Node.js is suited for some uses but it is a bad idea for others. When your single-threaded node server has capacity issues you might have to add another node instance. Now you have a multi-process server.
    – Joe
    Apr 17, 2013 at 10:20
  • I see what you mean.I will update the answer shortly(read after some research) Apr 17, 2013 at 10:23
  • 10
    It's not just about CPUs. The reason why it's important to handle every request as quickly as possible (in a single-threaded system with no other concurrency) is because the server cannot service multiple requests at once, so every request has to wait until you've finished handling all of the requests before it. Concurrency, done right, means less waiting. Use of threads is not inherently a performance drain, and single-threadedness (by default or otherwise) is not a performance advantage. Apr 17, 2013 at 11:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.