In response to

To address some of the points made

V8 is not server-class

that is true, but there are lot of cases where stuff that is not server-class is used anyways. I’ve seen hosting companies fill racks up with consumer-grade hardware and sell them as servers. What it really means is that it was not developed for the server market in mind, and won’t have all the fault tolerance of a server grade solution (stability). This is absolutely true for V8. It is meant for clientside javascript. As a result, yes there will be bugs, and there will continue to be bugs for the next few years, just as other platforms have faced, for the next few years. However there are also bugs in ruby, python, java, php, etc. etc. etc. Just maybe not as many any more.

Callback Spaghetti

This is an issue with node.js IF you don’t know what you are doing, if you have a 8 callbacks all nested, then you have a design problem or you are using the wrong language for the job.There are ways around the callback spaghetti that keep the code nice and neat. One of the biggest issues is the way we are used to thinking and working is drastically different than the way node works. Rather than execute things one at a time, it executes one thing after another without waiting for the results; so if you have x=2;y=1, y might be equal to 1 before x is equal to 2. This can be challenging, but it is one of the strengths of the platform if properly leveraged.

Non-blocking != fast != scalable

when they talk about node scalability, I really haven’t had the need to scale node or on any current projects forsee the need to, so at this time, I don’t know. However I know that some pretty big names out there are using it and I’m guessing they have looked at scalability.

non-blocking means that it doesn’t have to wait on other portions, a great example of this would be querying the database, or reading a file. you can return a page to a client, and just load in results as they come in (sounds easier than it is, but it is doable), or tell the database to write something and move on without waiting for a confirmation (handling the confirmation later when it comes in.). As for speed, this again comes down to language choice. I don’t think I would ever use node to calculate PI, Math just isn’t what javascript is good at. What I would do is ask another machine using a more appropriate language for the value of pi, and return it to the client when I get a response. This is what node is good at.


Some of his points here are very valid, however I find close minded. The important thing to understand about it is that ruby and python (and php) have all had growing pains. PHP only got namespaces as of v5.3 if I am not mistaken.

In closing, Node.js is not perfect, hell it’s bloody awful at somethings, sometimes gives unpredictable results ( for a good example) and the documentation is sketchy. I’m currently working on a number of projects using node.js, and if I where to document all the issues and bugs I’ve working through, this would be a much longer post (and somewhat embarrassing at times where a simple spelling mistake on my part had me cursing a blue streak at node). At times it does make me wonder if I’ve chosen the right language for the job, but when I look at the needs of the project, Node.js is a perfect fit for these applications.

For simple projects this is not a problem, for more complex projects, it means that, that it might take some time to get used to it, and figure out why stuff isn’t working. Once you get used to the way it works though, it’ll be clear sailing.

I say give it 3-5 years and I’m sure that not only will node be much better, but some of the improvements in node will seep into clientside javascript. In the mean time, it’s still a great tool to have.