i disagree with that type of rant. using a framework isn't about "making it easy" and "hiding the details". or at least, not to me. its about not having to mess with the details. repetitious, abstractable details waste time and energy.

its why we don't typically code in assembly. its a waste of time, and you generally have faith that whatever statement you write in, say, C gets translated correctly and efficiently down in to assembly.

I think it very much depends on what gets "abstracted away." If a library provides sensible defaults, or does some convention over configuration, it helps me ignore the inessential. And my knowledge is portable to other frameworks, I still understand the underlying model, I just don't have to mess with the details.

In this we agree.

But if a frameworks provides an abstraction that isn't isomorphic to the underlying model, I end up learning a non-portable technology that is useless when I step outside its cozy implementation.

For example, ORMs that hide SQL from me. Messing with SQL syntax may be inessential, but working with actual relations is my job, and not knowing how to use a database is counter-productive.

JM2C, YMMV, &c.

p.s. I forgot to confess my own sins:

https://github.com/unspace/faux

I think it mostly comes down to an individual programmer's style. "Glue programmers" will tend to prefer frameworks; other programmers won't.

I, personally, can't stand any of the PHP frameworks, or code frameworks in general. I hate having to get to know their individual quirks. I hate having to spend a lot of time getting accustomed to some other programmer's mindset and approach to problem-solving. I passionately hate those rare instances where I find an actual bug in someone else's framework; since I didn't write it, I probably had to spend a lot of time first assuming it was a problem in my own code, and then tracking the bug all the way into the framework until I found it. Cognitively, even though that doesn't really happen all that often, it's powerful reinforcement against using frameworks. In PHP's case in particular, I really don't see the point of frameworks, since it's such a high-level language to begin with. Why even bother having your own database classes when you have PDO, for example?

But, as a practical matter, I realize that programmers that do invest the time to familiarize themselves with certain frameworks tend to be a lot more productive than I am.

Really? Well anyone is free to invent bicycles: XSS protection, SQL injection prevention, defense against CSRF, caching, project structure, etc., etc.

The Django Book (http://www.djangobook.com) starts with these details (except for the the dispatcher stuff), then shows you how to cut down the boiler-plate code using django.

The book I read on TurboGears was similar, IIRC.

You start with the basics, use the framework to speed up monotonous stuff, then drop back to the basics when you need to do heavy lifting.

What he's actually talking about is a matter of preference. He almost completely misses the point of using a framework to not reinvent the wheel when you like the way the wheel's invented in this framework.

Some like plain HTML, some perfer HAML, some generate DOM tree, some like to have "components" and "controls" - and they're all equally right in their views. The same holds for SQL vs ORM.

Some frameworks hold TMTOWTDI views, when you could do things in a way you perfer. Other frameworks insist that there's one and only one proper way of doing things (in given framework).

Just use whatever suits your tastes well.