[tommorris]

"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.

[viscanti]

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.

[tommorris]

Ah okay. I thought you were referring to Rails, my mistake.