[DougBTX]

> I now need to buy-in to the entire (framework) mindset to progress which slows things down

That's interesting, that idea could be folded into the technical debt metaphor.

So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how it works, or you throw the whole thing out and use a different library.

[XLcommerce]

Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and were inflexible black boxes.

[eric-hu]

I have to say that I feel like Rails' ORM does a magnificent job of saving me time. Migrations allow me to write database changes that can be undone more easily.

An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help.

I have had to learn AREL, the relational algebra used by ActiveRecord, in order to do more advanced queries. That's analogous to learning SQL in more detail, but I'd still take that in a heartbeat over writing raw SQL. The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.

[XLcommerce]

I've not used the Rails ORM so I can't comment on how good it is or how easy it is to debug queries (peer behind the magic).

*The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.'

Maybe it depends on the system you're working on however mitigating syntax errors seems like a small benefit. For me the SQL for most projects is fairly static i.e. once a given set of queries has been defined and tested they can lie there untouched, so once I nail a query and it performs the way I like I hardly ever need to go back and touch it again. However the performance penalty of sitting behind an ORM is ever present, for each query (at least for a cache miss). Personally I just don't like having 100s of lines of code sitting between:

model->get(('model.field' => 'value'));

and actually receiving the data.

It just seems so.... unnecessary.

of course YMMV, and perhaps the benefits kick in when you're working in a team (I'm not).

[edwardtrunk]

great point! i like to share this previous experience. years ago while working in large os development teams my approach was it was not enough to write tools/automate such that less experienced folks could perform tasks that had usually been done by senior folks -- the implementation had to empower the folks with less experience to control their own destiny -- which meant simplifying the implementation to the extreme. This also empowered the senior folks too as often the tools are not a primary focus, they just want to get some done and on with it