The alternative to React is not Angular or another JS framework. That was not just my anti-React rant, it was an anti-SPA rant in general. I still fail to see w

The alternative to React is not Angular or another JS framework. That was not just my anti-React rant, it was an anti-SPA rant in general. I still fail to see why people need to build an entire application twice, once on the server, and again on the client, except perhaps when you have very frontend-heavy interactivity requirements (like photoshop-in-the-browser or games). SPA's attempted to rebuild the entire HTML web-browser model, and they did it poorly. I yearn for the days of Rails/PHP/Django where the server "is" your application, and we use the web browser's native functionality as designed, with a much simpler application model, and, in most cases, a better end-user experience. That's enough for 80% of apps. A little bit of DOM manipulation is acceptable (i.e. jQuery / Vue.js) and easy to keep track of in your head since every page is a new context/state, instead of ever-increasing layers of abstraction for "state management" and "components". If you write clean HTML, the DOM is much easier to deal with than some state management library. If you could truly abstract away the DOM without ever thinking about it, I would agree with you, but you can't. You can't escape thinking about the DOM if you care at all about performance and debugging, and now you have to worry about the DOM AND your state abstractions. I'm not saying we have to go back to writing assembly code, but I'm saying JS frameworks are the leakiest abstraction ever designed. That react-three-fiber project is cool, but engineering is not about you can do, it's about finding the best solution for a given set of requirements, and 95% of web apps don't need that kind of functionality - it's just unnecessary over-engineering at a huge overhead cost. React devs love to talk about one-way-data flow and Flux state management. They forget state doesn't come from the client, it comes from the server. Why not carry this one-way-data-flow model all the way back to the database, which is where your state actually originates?