Sometimes referred to as 'micro framework' architecture in Software Development vernacular. Let the down-votes begin!!
I actually think frameworks are too monolithic, and we feel the pain of that, but no one has figured out how to do something more granular yet. To a large extent that's a community administration problem, not a technical one, which is why you don't see a lot of computer scientists trying to do it. Though it will require some technical chops too.
Node/NPM, and UNIX before it, are attempts in this direction. It's not really gelling yet though. The various component systems are trying, but inevitably fail because they are trapped in a single layer of the framework stack. I think we need a few more breakthroughs in social organizational strategies (things like Flickr, Uber, Bitcoin, etc) before it becomes obvious how to do it.
It's dumb that the browser renders HTML, a framework bootstraps, parses the template, then re-renders the view.
90% of the front-end frameworks exist to provide templating + some special set of features.
If we standardize a pre-render hook to plugin custom templating engines then frameworks can shift to focus only on their implementation specific strategies (ex data binding).
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
You're very right, you really have to pick your battles. It's interesting since I'm doing more contract work and finding out that one shop uses Angular and another Backbone and a third React. Which one should I really learn and focus on, when nearly every shop has a totally different philosophy??
Even trying to pick the winners in these framework battles is getting exhaustive.
I'm still using knockout.js since I've used it for two years, it's maintained and each release is a big improvement in features and recently speed (massive improvements in 3.4).
Its not that react et al don't interest me but the switching costs are real and I'm not sure what they'll look like in a year.
How about, everything shifts to isomorphic rendering. Generate an interactive view stub to display on the client while the app bootstraps.
There's no justifiable reason why we should have to refresh and completely re-render the page every time the view changes.
From a 'business perspective' it's worthwhile to have front-end devs build all of the view logic (incl templating, routing, etc) on the front-end while the back-end team focused solely on building APIs, microservices, and data management infrastructure.
If back-end devs are responsible for everything incl templating, the front-end devs responsibilities are limited to... Photoshop, HTML, and CSS?
This is the year of the framework fatigue meme.
Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.