Programming

I think it's more a case of the tool being used, not because it's the best tool for the job, but because it's the tool the dev knows how to use. SSR allows frontend devs to become full-stack devs.

React and Vue already have lots of libraries, components, and know-how. You can also move from CSR to SSR and back depending on your requirements.

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

React works well in this role too because it supports SSR. This part seems to assume that React SSR is inferior to other classic backend HTML SSR solutions, which is not my experience. Even for static non-interactive content, the way React has you organize your code into components is a much better setup than most classic HTML template systems I've used. And then React makes it very easy to sprinkle in interactivity where you want, without requiring you to bridge unrelated server-side html templates and front-end code (which can often blow up in complexity and require work to be re-done separately on each side of the codebase). The same React components can be used in server-side rendering and client-side code, so whenever some new page interactivity requires the client to render something that was previously only server-side rendered, you don't need to rewrite the component's code in a new system and maintain two versions of it.

SSR is a overloaded term.

• There's SSR to help improve FCP (first contentful paint). This is not really so much an improvement to the client side framework as it is a crutch to workaround the fact that the frameworks are dynamically constructed clientside. But the first paint would just be Root node which is essentially empty. Because React and Vue are so heavily tied to the DOM structure, it expects to be the compositor of the tree, not something written in HTML. For pure HTML to be the compositor, you would need to add some rehydration to React/Vue to take a pre-composed state and reintegrate it into what React expects.

• SSR is also used to dynamically build content that is presented to the user that is not necessarily tied to rendering. This is popular with PHP, where instead of putting a blank table and then having the client fetch content over JS and then populate that table, the server just hands you the precompiled HTML. Not all the data as sent over JS may be useful (eg: only 10% is used after filtering and pagination), so to save transfer size and query latency, it may be the server that gets the always data from the store or cache. There's less client JS in execution, which may also help in performance.

• Then there's SSR for the purpose of improving SEO. This relates more to the first point, but maybe the first paint isn't important. Maybe client-side construction is plenty fast. But because the root is just blank, search engines that don't perform synchronous JavaScript can't actually read the content being shown to the user after all the rendering is said and done.

Personally, I've moved to Web Components that solves almost all of this. You can author layouts in HTML and anything that you want in your HTML file for SEO is included in the source. I would only use SSR to target the second issue, where you want to save on trips to build dynamic content. It is somewhat wasteful to give clients instructions to fetch and render when the server can do that on the first trip. The issue is rehydrating, or picking up from that state, but that truly depends on how complex your Web Components are. If they are sparse and simple enough, then all states should be able to be expressed over attributes. First paint can be reduced with the template shadow root, but I feel it's more trouble then it's worth and has negligible performance gains compared to just doing a prerender JS to register components and the browser will only render synchronously what's in the viewport anyway. That means time to first paint is not dependent of how big your page is. It's only dependent on how many elements you want to register before DOMContentLoaded.

From a financial aspect, I'm not about to ditch static CDNs to reinterpret nearly every single request with some server for SSR. The costs are nowhere near the same to try to reinterpret with SSR. You can micro-optimize to death with a SSR to CDN route and then hydrate, but I feel you risk complicating deployments to where you're so vendor-locked you have extra hoops to jump to make changes. God forbid you want to change frontend systems. At that point the DX pain is too much to justify and wanting to get out is inevitable.

Technically base html, css, and js are client side, so it is easiest to continue that. If you want something node based that is server, use express with stuff like mustache.

Cozx we went to a full circle. Back to sveltekit now until we find a better solution. Back then Virtual DOM was a feature, now it's more of a bug.