Yep. And this problem was "solved" long ago via client side templates, MVC from the server to the front-end. Keeping the model as a single source of truth was

Yep. And this problem was "solved" long ago via client side templates, MVC from the server to the front-end. Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it. Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly. The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub. Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used. Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone". What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is. Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex. It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS. Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"