I blame Facebook/Twitter/Social for this. With their rise in mid 2000s, having a framework with which you could manipulate the entire dom real-time to reflect

I blame Facebook/Twitter/Social for this. With their rise in mid 2000s, having a framework with which you could manipulate the entire dom real-time to reflect the state in the backend have been accepted as obligatory. Whereas in reality, aside from the neat templating that frameworks like React bring to the frontend, there is absolutely no need for the majority of web applications to be able to send micro updates to the client like how it is obligatory for social networks or other apps that are heavy in user interaction. The least thing that you would want to do when a user is going through an ecommerce checkout process is to manipulate the dom and change stuff that could distract the user from the checkout process, for example. If you need to update some info with the changing quantities in the cart or address, that could as well be done with simpler stuff like jQuery - considering that your site does not have such features that will cause your jQuery to bloat. There is even less need in the majority of the web where only content is consumed - how much interactivity do you need for a news article at the guardian or even your local-news blog? The user will just want to read the article. He or she may not even bother to comment (and likely wont), and when they comment, you definitely don't need a full fledged framework manipulating the dom to post and refresh the comments section. HTML and the browser already sort that out. ... The overall idea is sound, yes. A better form of presenting and manipulating the dom is a good thing. But, the bloated frameworks and the dependency hell that we created for ourselves do not look like the way to do it.