DEV Community

Discussion on: Why I don't care if you disable JavaScript

storytellercz profile image
Jan Dvorak

True, from what I have seen people want SSR for SEO and to get them to render on client super quickly to satisfy Google metrics (hence SEO).

Thread Thread
thumbone profile image
Bernd Wechner • Edited on

Actually looks like I misunderstood SSR? I just read this and it puzzles me immensely:

techstacker.com/server-side-render...

The difference seems very very subtle. Both seem to allow client side code, and they claim SSR simply provides the initial view so it can be seen while JS downloads while CSR doesn't (you see the view after JS is downloaded and renders it).

To be honest most of my experience is with templates that provide basic page layout and initial views indeed, and then interactive elements that need to respond to changes in data are rendered by client side JS, generally filling in spots left blank in the original template.

But to be honest I wonder about this whole "while JS downloads" as the real experience I have 95% of the time, maybe 99% of the time is that this time is negligible. And that would be because the bulk of the JS (the libraries) is locally cached already due to either my earlier visit or being standard shared CDN delivered library material. Heck most of the delays I get in page presentation are server side costs generating the data, but then I have some complex data I work with, spanning many tables and relations etc in an RDBMS ;-). But to speed that up I manage my own server side caches too (as does any site really) so that once a given view is generated it's available quickly for some while thereafter or until invalidated.

Still, I cannot imagine anyone disabling JS generally unless they are content with a tiny portion of what the web has to offer. And my learning in this read was that SSR permits client side JS and refers only to the initial view render.