People are really excited about node.js.
Not just node.js though: erlang, scala, and clojure are all getting their fare share of hype and attention.
The one thing all these platforms have in common is that, today, building traditional REST applications is still significantly more difficult, at least conceptually, than in Rails or any of the other popular MVC frameworks available in other languages.
Then why is everyone so excited?
The first time I used node.js I found it much easier to build the kinds of applications I had been working on at the time. Until recently I've failed to identify exactly what it is about these applications that makes them easier to build in node.js and why I've left behind all the comforts and maturity of Python and other platforms.
I used to think it was Realtime. That's what the hype train seems to be preaching. But when I started to dig in to the previous generations of applications and the platforms that have continued to dominate them I realized it's much bigger than realtime.
Way back in the day the web was all static content. Files were either edited by hand, pushed via FTP, or written out by some desktop software. The files were served statically, so the problem to solve for applications at the time was serving static content.
Apache web server won. Mainly because it's competitors were proprietary but also because it was simpler and faster than it's contemporaries.
Then a new type of web site emerged. All of a sudden the amount of information a site might need was just too big to deal with as static content, rebuilding could take days for a simple styling change, so the problem to solve became "how do we quickly and simply render HTML assets from a database backend?".
The outright winner was PHP and, in fact, if this is still what your application looks like it's still the better choice. You barely need to know more than HTML to get a site like this working in PHP.
The important thing to remember about these applications is that HTML delivered over HTTP is solely the renderer for this data. For the most part these applications had entirely seperate workflows for getting data in to the database. The applications were all silos viewed as HTML via PHP.
Then the world was washed in buzzwords. Ajax was all about turning your "web site" in to a "web application" and web2.0 was starting to change the relationship between the web and the database.
The web was no longer just the renderer for the database, it was also the writer. The relationship between websites and the web became bidirectional. Now the problem to solve was "how do we build web applications that can easily display and write data?". The MVC pattern began to emerge and was, by far, the best solution to this pattern, with Rails being the leader.
But for all the web2.0 talk about APIs most applications had a bidirectional relationship with a single database and not with other web applications. Applications rarely called out to other web services and when they did the integration wasn't very deep.
So, what is the problem to solve today?
Here's what I've observed.
Applications now need to have many inputs and many outputs. It's not enough to talk to just one database. You might have 2 or 3 databases behind your application server and also need to talk to various other web services.
You also have all these "push" or "streaming" services. The new twitter APIs, Redis channels, the CouchDB _changes feed. These are all pushing state to applications. That means the application process needs to be long lived and have some shared readable state between each line of concurrency (user) who may or may not be connected.
There are also considerably more delivery networks. SMS, email, mobile notifications on Android and iPhone. It's not just an HTML page and an RSS feed anymore.
This is a much harder problem. Some of these remote sources need to be handled in parallel or performance would be unnacceptable. Others may actually require some sequential requests. All combined with handling shared state that might be pushed in to the application process.
MVC isn't the right pattern for tackling this problem. A better pattern hasn't emerged yet but even without a pattern platforms with better concurrency patterns are a much better fit. You need a long running process with some shared readable state to handle newly pushed information. And if any of your remote data sources is async (a write will return nothing, but an event may be "pushed" to you later that contains the result) then it becomes incredibly painful to artificially block a thread if your concurrency pattern is primarily blocking like it is in Python, Ruby, PHP, etc.
I don't think we're seeing an application framework pattern anywhere that fits this problem well, mainly because it's been so hard to identify.
What we used to build the previous generations of applications isn't a good fit for the next generation. This is nothing new, it's happened before and it's likely to happen many more times before I die.
That's what all the excitement is about. Yes, it's still much easier to build a RESTful application that talks to a single database in Rails than it is in node.js. That will likely never change, just like Rails isn't simpler than PHP at quickly displaying a web page from a database. It's also irrelevant.
What makes a platform or pattern great at dealing with one problem is precisely what makes it terrible at another. The problem has changed and we need something new to solve it.