I mostly agree with this, and also with the parent poster. I've seen framework become a big problem, and I've seen shitty ad-hoc frameworks for "framework-less"

I mostly agree with this, and also with the parent poster. I've seen framework become a big problem, and I've seen shitty ad-hoc frameworks for "framework-less" applications. I've had fairly good success with what I like to call "framework libraries". That is, all or most of the functionality of a framework, but composed more as a library (or rather, a set of libraries) than a framework, giving you the best of both, mostly. ORMs are often given as an example, but I rarely found them as issue as most I've used have an "escape" to allow you to just use SQL if need be. The bigger problems with frameworks are when you want to compose some application in a way the framework doesn't really like (this can be a problem in Rails, for example). I aggressively push things to libraries whenever I work on something; sometimes they can be made public, sometimes not, but even when private it helps a lot in mentality of people, especially with certain kind of devs.