zaydek
commented
3 years ago It seems like there is a sweet spot. If we have SSR for head-tags only, then we solve the SSR problem in an ideal way. Those pages basically can be CSG / CSR but are SEO friendly because that is exactly the problem head-tags solve for.
Goals may very well be SSG and SSR but SSR seems to be a little bit of a misnomer.
Why?
SSR means you have a server — and therefore a program — to dynamically render pages. What’s wrong with this? Well, basically this is not stateless. This means you inherit the following concerns: CORS, reverse-proxying, certificates, server monitoring / maintenance, etc.
The benefit of only concerning yourself with SSG and CSG is that your app is stateless for all intents and purposes. You are choosing whether you want to pre-generate pages for users, but you’re not forcing users to talk to your server rather than some hosting provider.
If you look at how Twitter, YouTube, or Instagram work, it looks like they defer to a JSON-encoded / JS object to derive views from. This seems a like a halfway point, where views can be generated client-side without additional backend requests. So these are not entirely server-rendered, but they are also not entirely client-rendered either. They are sort of client-hydrated, from what I can tell.
The question we want to consider is whether server-rendering is actually important or if CSG and SSG are enough.