nonblocking i/o is an important feature if you want to make something responsive that will handle a lot of connections. node.js brings that to the foreground, and makes it a topic that is digestible for a lot of programmers that have never seen it before. The end result is that by using node.js, a developer is able to experience one element of concurrency that they may not have had exposure to using Ruby/Python/PHP. Yes, it is possible to do nonblocking i/o in Ruby/Python/PHP, but it isn't as natural of an experience.

It's a usability thing. If you make something easier to use, more people use it; as a result, node.js has introduced the topic of nonblocking i/o in a way that other technologies have been unable to do. It also allows you to share code between the client and the server, which may or may not matter, depending on your project. And for a lot of developers, node.js means using a language you already know.

The guys at Kitchen Table Coders do a workshop where they make a physical game paddle with an arduino, and then hook it up to a node.js server, so that two people can play pong with physical controllers in their browser. They're able to teach that workshop in a day. I think that speaks volumes for types of things that you can do with node.js, and its mass appeal.

But, like I said in the article, I find that node.js becomes disorganized quickly, and I just plain don't enjoy debugging JavaScript. On top of that, if you need to do CPU-bound work, node.js basically forces you to create an isolated process and perform i/o with it, but now you have an OS process for each of these instances, whereas in Go, creating a goroutine and communicating with it over channels is much more lightweight. Node.js has its merits, and I don't mean to say "nobody use node.js ever!", I just don't like using it.