The bulk of today's web devs are coming from Rails and it's nice to have that hand-holding when you're trying to cross that chasm. Besides, a lot of the concepts that RoR were built on are sound (i.e. don't reinvent the wheel every time you make a new project), even if Rails has become as bloated as the technologies it replaced (J2EE, .NET).
>The bulk of today's web devs are coming from Rails
Ahem, you're exaggerating there just a little bit. There are probably around a dozen web frameworks that are competing for the spotlight right now. With Zend, CI, Django, Symfony, Struts, Cake, etc. all equally if not more popular it's hard to say Rails has the "bulk" of today's web devs. I wouldn't even go as far as saying that the bulk of today's web devs appreciate MVC.
Who cares how many people use these frameworks, most of them are using the same MVC structure and are just stealing features from each other.
Some of the Node people like things small but when applications get bigger putting things into an MVC structure often makes your code more organized. Until someone comes up with a better idea that takes off this is how things will be done and I think it's great that Node has a few choices now to do this.
There's a difference between using an MVC pattern (which is easy with Express, but is completely optional) and relying on an ORM (which the project forces on you). One of the great things about minimilist frameworks like Express is that you can build it out and customize it like you need.
The types of projects that benefit from being in node.js instead of Rails, Django, etc, don't really benefit from having all those decisions made in advance. If the "Rails Way" works for your project, you'll probably benefit from doing it in rails. There's certainly more library support and it's easier to find more experienced developers for Rails than node.js.
There's a tendency to put all kinds of projects in node now, just because it's "hot". Some projects benefit from node, and some would be easier to do in some other language/framework. If you're experienced with Rails and are working on a project that fits that style, you're probably better off just doing it in Rails rather than switching to node and using a Rails flavored framework.
"relying on an ORM (which the project forces on you)"
By the project, I presume you mean Rails. Because Rails doesn't force ORM on you. It assumes that by default, but if you don't want to use an RDBMS and ORM, you simply remove the inheritance from ActiveSupport::Base from your model class and write a class that talks to whatever you prefer.
Rails makes the reasonable assumption that most people will be talking to an RDBMS. It could omit that and instead you could "build it out and customize it like you need", but that way lurks 7,000 line XML config files and all the other crap lots of Rails folk were trying to escape from. The point of convention over configuration is that for some baseline assumption of normal, it comes ready to rock and roll.
No, the Rails inspired node.js framework forces an ORM on you. My advice throughout this thread has been to stick with Rails if the Rails conventions do it for you. There's certainly nothing broken with that approach. I don't think Rails is the right tool for every problem, but for the ones that it is, people will probably be better served using that, rather than re-implementing it in node.
I'm neither anti-Rails or anti-ORM. But the types of projects that actually benefit from being in node, rather than Rails generally benefit from not being tied to those conventions. If what you're doing fits the Rails pattern, that's probably a better solution than anything in node. If you're doing a project that doesn't fit that, and you need lots of customization, you're probably better off doing that from scratch (or with a minimal un-opinionated framework).
I think both have their places. It really depends on the project.
