Also it's not like CSR is mostly used just to render out a flat document. It's used mainly for interactive stuff, often just banging internal client side state and not even talking to an API. And even when the client is talking to an API to update a small part of the document, this is more straight forward, than having a full client-server round trip, just for updating that small part.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration.
The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration. The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.