I have read a lot recently about Node.js, and it seems to be the flavor of the week right now. The gist of Node.js is that it is Javascript on the server, and it uses a "event-driven, non-blocking I/O model that makes it lightweight and efficient". That probably doesn't mean a lot to most people, even many programmers. Suffice to say that when you run a command, you don't wait for it to complete, hence "non-blocking".
As an aside, I'm going to completely brush over the fact that Javscript is slow. Let's pretend it's as fast as other web languages (it's not).
At first glance, that seems like a great way to write software. Waiting for a disk is the slowest action on a computer these days. The typical time scale for a call to the harddrive is at least a factor of 10 slower than other commands. That's exactly the kind of thing you would want to avoid. Here comes the pitfall though, didn't you make that call for a reason? Don't you need the result of whatever you just asked for?
After reviewing every web-app I've ever written (or at least the ones I remember), I couldn't think of any instance where an intensive call was made that didn't require the result. If I make a call to a database to get some data, I'm planning on using it and displaying to the user. So that begs the question, when would you not care about the function result? I can only think of a few instances.
The most obvious are calls where you are logging information to non-volatile storage. Let's say I update my account, you may want to log what the previous values were and the new values. This gives you a "paper" trail to follow. While this is a legitimate use, I can shoot holes in it as well. Should I really completely rewrite my program for something so simple? Why not just make sure the logging system is fast? SQL Inserts are fast. Increase the RAM on you database server. Make sure your database is tuned properly. Queue your logging calls so they run after you've finished output and flush the output buffers.
Another would be when using WebSockets. WebSockets are great, because they give you a persistent connection to the server. So requests can flow in real-time, rather than on a polling schedule using AJAX. Running Javascript on the server and client side would also make sense. You can easily pass JSON back and forth as needed. The main problem here is that WebSockets are currently only supported on three browsers. Going beyond that, what data are you actually going to be passing? Primarily data going into a database most likely. Here we are again, stuck waiting on a database, but this time we have to have the result. So I'm not speeding up the request time, I still have to wait for the database to return data. All Javascript gives you is some horrendous code. I've heard it referred to as the "pyramid of death". Basically you get buried in callbacks, giving a pyramid shape like so:
getData(param, function() {
processData(param, function() {
sendData(param, function() {
...
}
}
}
Now just imagine that actually did something useful. You can easily see how bad things can get.
Those are the best examples I can come up with for a time when Node.js might be useful. It was even talked about at the ConvergeSE conference during one of the workshops. I came away feeling as though all of my complaints had been validated. The speaker showed some interesting applications, but none of them needed to be in Node.js. They could have been in Ruby, PHP, Python, C#, etc. I've even spoken to people that have used Node.js in production, and they openly admitted that it was a complete mistake, and they were working on replacing it. Turns out, it was slower than Ruby on Rails.
Either way, if someone can show me a use that makes sense, I'll be glad to look at it. In the meantime, Node.js is just a hip fad being pushed by people that want something new to talk about. People that like buzzwords, in this case "non-blocking", "event-driven", and "real-time".
I'll close with a wonderful video summarizing the problems with Node.js with humor. Also, a little NSFW due to language.