ok look people. I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed: View

ok look people. I think what is needed is to recognize that the SPA architecture isn't actually just a view processor. IMO it is a very shitty designed: View rendered <--> client process <--> server process So it seems that SPA apps load an absolute mountain of javascript into the view (the tab/page) and then that starts (crudely IMO) running as client-side daemon tracking messy state and interfacing with local storage, with javascript (opinion: yuck) ferreted away in a half dozen divs. IMO, what has been needed since you have local storage and local session state and all that is ... a client daemon that the web page talks to that offers data services, and then that client daemon if it needs server data calls to the internet. That way local state tracking, transformation, and maintenance can be isolated away from the code of the view. Large amounts of javascript (or maybe all with CSS wizardry is dropped). The "client daemon" can be coded in webassembly, so you aren't stuck with javascript (opinion: yuck). You can even have more efficient many views/tabs interfacing with the single client daemon, and the client daemon can track and sync data between different tabs/views/windows. Now, of course that is fucking ripe as hell for abuse, tracking. Not sure how to solve it. But "separation of concerns" in current web frameworks is a pipe dream.