Interesting thoughts about the evolution of the web and the problems that people are solving. However, designing applications that require state to be maintained in a single process can come back to bite you in the ass when a single process can no longer keep up / falls over. Most people don't hit that ceiling, but then again most people's systems are "just fine" with having a thread blocked on their I/O.
I like node.js because it is much faster than ruby and it provides a very thin layer of abstraction that takes most of the pain out of dealing with async io. I also happen to like JavaScript as a language. Further, I enjoy developing in primarily one language as it reduces the cognitive burden of context shift between front and back-end development. Finally, I enjoy the node.js debugging tools more than anything ruby has to offer (thanks Danny Coates and the chrome dev tools team!)
However, telling people that you cannot connect to multiple databases with ruby or python and saying that node is unique in its ability to build systems that maintain state within a process isn't intellectually honest; node.js doesn't have a particular advantage over netty, eventmachine or twisted for the particular use-cases that you gave; there are already non-blocking variants of most of the libraries available to the node.js community in python, ruby and (increasingly) java.
While I appreciate the fact that many "traditional" MVC frameworks fall down when it comes to threading, events, long running connections, event handling, actor-based concurrency, asynchronous processing, and multiple data / presentation resources ... I don't think MVC is the root of the problem.
In fact, MVC doesn't really have anything to do with those issues: it is a pattern addressing the separation of concerns, whereas the shortcomings in the article relate to specific implementation of frameworks that also happen to follow the MVC pattern.
That said, there certainly is a new direction emerging for web applications: we're entering the world of sophisticated software. :)
The author gives an analogy which implies that node.js makes Rails irrelevant for a certain kind of apps, but I'm not convinced by the examples given.
In addition, if you're making a single process talk to a PostgreSQL, Redis and CouchDB database, send email and SMS, and talk to a couple of APIs then you're doing it wrong.
I'd like someone to show me the code and a real example.
I like node.js because it is much faster than ruby and it provides a very thin layer of abstraction that takes most of the pain out of dealing with async io. I also happen to like JavaScript as a language. Further, I enjoy developing in primarily one language as it reduces the cognitive burden of context shift between front and back-end development. Finally, I enjoy the node.js debugging tools more than anything ruby has to offer (thanks Danny Coates and the chrome dev tools team!)
However, telling people that you cannot connect to multiple databases with ruby or python and saying that node is unique in its ability to build systems that maintain state within a process isn't intellectually honest; node.js doesn't have a particular advantage over netty, eventmachine or twisted for the particular use-cases that you gave; there are already non-blocking variants of most of the libraries available to the node.js community in python, ruby and (increasingly) java.