Obligatory link to the best ever libraries-vs-frameworks post in the history of internets: http://term.ie/devdev/why_frameworks_suck .
Choice quote: I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.
Choice quote: I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.
But if you're any NIH on the side, the framework-as-bunch-of-easily-integrated-libraries approach really makes more sense. It also lets you try a framework incrementally, therefore decreasing risk instead of committing to a behemoth framework prematurely.
My framework would ask me how many people I want for dinner, what mood I'd like, and what should be on the menu. Then it would surround my table with exactly the right number of chairs, lay out appropriate crockery and cutlery for the courses, and switch on suitable lighting and music.
It would also give me a facility to override its choice of lighting and music to specific settings if I wanted to, and a way to tell it one of my guests is left-handed and another is a vegetarian so their places at the table can be adjusted accordingly.
Of course, my framework would suck at laying out food for a finger buffet for 50 at my big party, but then if that's what I wanted, I doubt I would have started with that framework anyway. And I'd still have to decide on the music and lighting.
The facility for including a child at the dinner just says //TODO.
In a decent framework, there are usually hooks for lots of stuff, but much of the time you don't use any particular hook because the default behaviour is what you want. In your case, it ought to have been possible to override the vegetarian dish preparation with a version completely of your own creation if you wanted to.
But in any case, there's not that much difference between this and building a project around a specialised library that doesn't have a whole framework: you're still screwed if you discover late in the proceedings that it's got nasty bugs and whoever produces it isn't willing or able to fix them. (If you get to invent another library that conveniently provides the same interfaces and has no bugs to use as a drop-in replacement, I get to pull an interchangeable and bug-free framework out of the same magic hat.)
The effort of replacing a library should not involve restructuring all your code as if you were replacing a framework. If you find yourself restructuring your whole code to accommodate changes in the library, maybe it was a poor library, too framework-like. :-)
I guess the distinction just seems rather artificial to me. It may theoretically be riskier to use a framework, in the sense that working around its limitations may be harder to do in the worst case. However, if you're working with bad interfaces and reluctant support, and the library is of any significant size and complexity such that you couldn't just reimplement it yourself in a worst case scenario, then you're basically screwed either way. Being only 75% screwed instead of 85% still doesn't ship your product. :-)