At our shop we don't use frame works, well at least none that came from anyone else.
The problem with frame works is that if you need to modify them, then you no longer can just update them when everyone else does. You are stuck always making changes to the framework ever after as they new ones come out.
But also you don't often fully know what the code does. If you have code that does something you don't understand then you end up not understanding how it changed later.
With Front End Development things like TwitterBootStrap get you a great looking site very quickly, that is nice. But if you want to tweak things suddenly your version isn't going to be the same as the stock version and you can't have it be cached from some fast CDN, and so your site is slower than it should be.
With BackEnd small changes to the official version of a framework can introduce bugs. Sure this is also true of things like Minor Revs to the language. (A lot of people got burned by moving to PHP 5.4 before WordPress was ready for it, and had only decided to enable auto updates to PHP because WordPress 3.2 required PHP 5.1) (And I'm not fond of PHP or WordPress so don't flame me because this is my example, it was one of many, but one that a great many people experienced so I figured the enormity of the event made it a good example)
The moral of the story is OWN YOUR CODE. The more you rely on other people's code the less you are the master of your own fate.
"The more you rely on other people's code the less you are the master of your own fate"
To head it off at the pass, comparison with shared libraries and the like are unfair.
A typical library has one, usually simple, well documented demarcation point between your code and it. A framework is a global construct where you interact with the filesystem, the combined sum of all code in the entire framework (most of which you won't understand unless you're a dev on the same framework...) AND everything else in your app.
Using a framework is often like writing one big app all global variables all one giant function. Everything interacts with everything else and when it works thats nice, but when it doesn't...
Finally a framework is the ultimate SPOF single point of failure. Don't like the play! framework router? tough cookies do write your own entire framework or forklift upgrade to Lift. On the other hand if library implementation #7 of a base64 decoder doesn't work or you hate it, try ten other implementations or write your own, its just one small-ish function not a giant overbearing framework.
Finally don't throw out the baby with the bathwater. If the syntactic sugar of MVC design works for your app, run with it. You don't need a framework to tell you how to design to split your views and controllers and models. Or if you're just in love with the template engine component of a framework, go for just a template engine.
Someone should write the framework to rule them all which supports multiple plugins. An infrastructure.
Need to include a qualifier that they're identical size/complexity. I find it hard to believe an app exists for a serious "bulky" framework that uses 99.999% of the code in the framework. Once you get down to 0.1% or so it starts getting easier to maintain your own ten lines than to cooperate/tolerate someone elses 10K lines.
So what happens when you write a seriously hard to solve bug or you accidentally misarchitected your internal framework in some fundamental way that wasn't clearly obvious until you're too far down that path to fix it? What do you do when the 1 to 10 of you that "own it" aren't smart enough to figure it out? What happens if that mistake is time sensitive or extremely costly?
The problem with frame works is that if you need to modify them, then you no longer can just update them when everyone else does. You are stuck always making changes to the framework ever after as they new ones come out.
But also you don't often fully know what the code does. If you have code that does something you don't understand then you end up not understanding how it changed later.
With Front End Development things like TwitterBootStrap get you a great looking site very quickly, that is nice. But if you want to tweak things suddenly your version isn't going to be the same as the stock version and you can't have it be cached from some fast CDN, and so your site is slower than it should be.
With BackEnd small changes to the official version of a framework can introduce bugs. Sure this is also true of things like Minor Revs to the language. (A lot of people got burned by moving to PHP 5.4 before WordPress was ready for it, and had only decided to enable auto updates to PHP because WordPress 3.2 required PHP 5.1) (And I'm not fond of PHP or WordPress so don't flame me because this is my example, it was one of many, but one that a great many people experienced so I figured the enormity of the event made it a good example)
The moral of the story is OWN YOUR CODE. The more you rely on other people's code the less you are the master of your own fate.