The evolution of the front-end web stack surprised me with the appearance of jQuery. Web developers, at the time mostly unskilled in structured programming, suddenly had powerful tools to go make a big mess with. Back in these dark ages, management often viewed front-end work as not worthy of software engineering, laughable as that is today.
Websites either adopted solid frameworks such as Dojo, YUI 3, built their own ones in-house, and so forth, or found themselves several years later totally clogged with endless jQuery-based sewage, unable to update or maintain their sites. In most cases, jQueryUI was used to drive the final nails in the coffin.
I'm sure these businesses saw substantial impact to their bottom line as well, on two fronts. One would be due to offering such a poor user experience, and the other from the vastly increased costs of maintenance and updates. Meanwhile, looking at the job market overall, developers who had mastered the MVC frameworks were much fewer in number and always had strong demand for their work.
Like a raincloud appearing on a bright picnic day, jQuery (through no fault of its own, excepting jQueryUI) stopped engineering progress in its tracks by about 2009, save for a few islands of sanity. Other shops went completely overboard in the opposite direction, trying to cover the browser in a layer with frameworks like ExtJs and GWT. These approaches often addressed browser shortcomings, but presented their own unique, and often equally bad, set of bugs. Worse, these overengineered solutions were slow to load for users at that time.
Today, with the benefit of computer/phone and browser speed, and development tools such as incredible compilers (for example, Google's Closure), we have the option to to upgrade to a data-flow architecture in our web apps, accomplished with a functional programming style. Instead of building an elaborate caching system as in MVC/object-oriented approaches, with the innumerable bugs resulting from mismatched state between objects, we can recompute from fundamentals. Facebook/Instagram's ReactJS does this well for presentation; the Flux-style architecture, or alternatively channels and go blocks (more on this below), organize the data and networking; and the Clojure/Script community has also offered some good approaches for managing application state.
The experience of working in a data-flow and functional style reminds me of how using a proper MVC framework felt in comparison to my first forays in front-end programming, 15 years ago. But, sorrowfully like a fierce cloud on a picnic day, Angular, kind of a perfection of the old MVC approach (perhaps morphing it into a "model-view-presentation" variant of the basic MVC, where the view takes over the somewhat-reduced imperative functions that are in the controller in classic MVC), offers developers a great way to . . . stay stuck in the patterns of the past.
Once again, as with jQuery, I see the majority of development taking the easy, overly-trod way, and foregoing the tremendous benefit of what is really not all that hard to do. The upside is that for those willing to take the leap, the advantages will provide a boost through this next phase of front-end development, similar to what the MVC developers enjoyed through the jQuery times. In fact, the thinking behind React is so disciplined and sophisticated (in the simplifying sense of the word), and the uptake strong enough, that I do think that Web/Internet-based applications will shift over in the coming decade to isomorphic applications built with a language that really fits data-flow architecture and functional idiom, Clojure/ClojureScript, as for example Prismatic has.