The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume thi

The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume this means the app they're working on during the day should be "rewritten" in the framework-du-jour. Then they hit that 20% "wall", blame the framework as "lame" and start hunting for an alternative. Rinse and repeat. Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it. To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.