The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a great story. Unit tests, integration tests, consistent layers, convenient and powerful ways to access the database without writing a giant SQL generator (if x return "and b.id = c.id" else return "b.name = "%" + name + "%")...
But then, you hit the use case that the framework didn't consider. And suddenly, you either need to extend the framework (never pleasant) or go outside the framework for one portion, which means building all of the tools from the ground up.
Or, more often, ignore testing, hack in the best way you know how, and hope nothing breaks.
The library approach means that you have to build the integration pieces yourself. This is painful, but it means that when you reach a new use case, it isn't as large a jump to keep going.
Each has tradeoffs. There are times when each is superior. Someone like Bob Martin would suggest that you build your system independent of frameworks and treat the web as a client/compatibility layer, and that you build your system of small composable parts so that the framework/library question is a minor one. (This has its own tradeoff with an abhorrent amount of plumbing code that comes along.)
It all comes back to the problem at hand and how we judge the tradeoffs, like most engineering problems.
I don't know what it is about the web, but it's as if we decided all of software architecture didn't mean anything and threw it out. My theory: it's harder to feel coupling in a dynamic language, thus it's just an academic concern!
It isn't that we've decided that software architecture meant nothing; rather, we settled on one architecture that is Good Enough. The View/Controller/Domain paradigm of Rails works for many projects.
Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.
A lot of the 'glamour' in the Bay Area is around web apps that 20-somethings use. As a consequence a lot of the headlines and centers of discussion are going to be around languages, platforms and paradigms that reflect that. And, these days, that would be dynamically typed languages, frameworks or framework-like 'libraries' and fad-following (which is where the "rock-star-ninja" meme comes from). I just try to filter the noise as best I can to glean the useful and interesting bits of articles and comments I read.
This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love, and so they create more jobs for this labor market to fill, which means more people want to fill it (since there are jobs there).
Edit: 1) I would disagree that python is a "lousy" language; 2) To give some perspective regarding where I come from, the vast majority of my experience is with statically typed languages like C, C++ and Java; I prefer them and in my experience they are at least as easy to develop with as any of the dynamic languages that are popular.
Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).
There is very little in terms of "provability" that either C++ or its types give you. Proving anything really interesting (for example, the absence of race conditions in concurrent code) still seems like pretty much an arduous process in languages not explicitly designed for such things.
Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).
That didn't seem very comprehensible to me, but if you're claiming that in Ruby, you can modify member variables of someone's objects, well, you can't, unless you use reflection as well (not only that, but the access to member variables is object-based, rather than class-based, so you can't access the member variables of an object from any other object, even if they are of the same class, unlike in C++ - so much for the "objects communicate by passing messages" in C++!). More to the point, in C++, you can always cast a pointer into something that makes the raw data accessible. There's enough stuff in C++ for you to blow your whole leg off instead of just shooting yourself into the foot.
In C++, you may not be able to prove "the lack of race conditions", but you can prove things like "I'm the only one who is holding onto this mutex right now" thanks to stuff like unique_ptr... which tracks that stuff. These primitive proofs are performed at compiletime, and have little-to-no effect on runtime as well.
Stronger languages with stronger type-systems (ie: Haskell) can prove / disprove which code has side-effects... because you've explicitly passed the Monad around. (Note: Code without side-effects is guaranteed to not have race conditions).
So yes, there are important things you can prove using the type-system. More importantly, it is the compiler's job to automatically conduct these proofs every compile cycle.
Seems to me that's a chip on your shoulder; not mine.
I'll freely admit that it peeves me to no end when people make value judgments based on what programming languages people do and don't like and use, on both sides of the static/dynamic divide, so maybe I do have that chip on my shoulder.