I've done a full circle on this one and arrived at -- it depends on the team. Specifically, if you have teammates who know the purpose of these frameworks and a

I've done a full circle on this one and arrived at -- it depends on the team. Specifically, if you have teammates who know the purpose of these frameworks and all their parts, they might do well with a leaner library based approach. But i've met many devs now -- some much stronger in general than myself -- who I later realized don't actually know why these things exist. So they go without a validation or jobs layer from the start, and then we have to do a bunch of refactoring after a few months. My sniff test is to ask people about ORMs. If the person dislikes ORMs because "I know SQL, I don't need help with it" -- they probably don't know that ORM's _mostly_ exist to provide the common abstractions over SQL you'll inevitably need (or make) in a business logic heavy web app. A more experienced (with web frameworks) dev should use (or not) an ORM for more thoughtful reasons than "I know SQL" or "I used X and it sucked so I'd rather use nothing". In short I generally agree, but I think some teams (in some contexts) can thoughtfully choose a more lightweight approach.