I think when trying to understand SSR, it's worth remembering what actually was happening with older systems like PHP. You say that outputting HTML in PHP is `v

I think when trying to understand SSR, it's worth remembering what actually was happening with older systems like PHP. You say that outputting HTML in PHP is `view = f(state)`, and this is to a certain extent true, but it meant that anything on the client side was then `view = f_client(state_client, f_server(state_server))`, and getting applications to remain sane with anything more than the bare minimum of interactivity was painful. I remember this era, and debugging constant state issues was very much the reason that we ended to moving towards client-side web frameworks: you only have to worry about one `f` and (mostly) one `state`. In my experience, most of the people exploring SSR are very acutely aware of that era, both the benefits and the negatives, and are trying to build systems that allow developers to retain a consistent overall view function without having to maintain that across multiple codebases in multiple languages. That doesn't just mean rendering HTML, but also ensuring that the frontend and backend agree on how to update that HTML if the state ever changes, or ensuring that progressive enhancement is possible while not requiring the entire site to reload every time I update a form field. Now I think there's a good argument to be made that many applications don't need this additional complexity - they can continue to be rendered entirely server-side, or entirely client-side, and not need to share state at all. But if you do need state to exist in both the server and the client, modern SSR frameworks are typically a pretty good approach.