DEV Community

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

Collapse
 
thumbone profile image
Bernd Wechner

Really? Where do you see such a trend? I have if anything, suspected the opposite trend. To more and more client side code. The popularity of CDNs in delivering it is huge, because the likelihood that you already have JQuery, Bootstrap, React or whatever cached locally because most sites use the same CDN (cloudflare is huge) is quite high!

Thread Thread
 
storytellercz profile image
Jan Dvorak

Not sure if Jan is referring the SSR everything people in JS community. I have seen a few people around Meteor demanding more SSR on par with Next.js and even in case of Next.js it seems weird to me. These are full JS apps.

In my use case besides index I also have a few other pages that I want to be able to index or be accessible enough for nice boxes on social media, but these days with a bit of help most search engines and social media handle that.

Thread Thread
 
thumbone profile image
Bernd Wechner • Edited

SSR puzzles me. I tend to transmit data to the client in far more efficient formats, typically JSON and have client side code to render it as desired. Also allows the client to alter rendering and have a load of options for rendering that involve no server round tripping. I'll take a look on-line as I'm curious about trends in this space, but I've never detected yet a trend to render HTML server side (that is the old school way, using static of PHP generated HTML - or even in its day Perl and other CGI related HTML production). The modern trend has been to create client side apps that request data from the server as need (AJAX), as far as I can tell.

Thread Thread
 
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

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.