This is highly subjective and argumentative. If you think different, please comment!
I love to develop highly interactive and complex apps - that ...
For further actions, you may consider blocking this person and/or reporting abuse
Out of interest, what is subjective or argumentative here? All seems obvious to me ...
I mean folk (like me) disable Javascript on websites, primarily in a response manner. That is it's enabled generally, I mean the vast, and I mean vast, majority of sites you visit don't work well or at all without it. But if something is awry, something is fishy, then on a given site (usually with a browser extension that provides a toolbar button) we turn it off.
To be honest one of the greatest use cases for turning off Javascript selectively is on sites that render their page and then mask most of it with a pop up demanding subscription. Often (not always) disabling Javascript sees the underlying page rendered and legible and the pop up and masking not appear. Of course a savvy web designer would not let me get away with that but many do ;-)
It's subjektive since the recent trend argues for removing Javascript from your rendered page at all. For performance or because people could disable JS or whatever reasons I simply don't get. Things will get more complex so unless it's a total static Peage like a Blog I can't see how that's something I even want to achieve 🤔
And yeah I agree with you on these shady subscription popups. Fortunately my apps don't have such dark pattern 😄
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!
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.
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.
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).
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.
I'm with you, if this is indeed a trend or a hype of requiring "your site should work even with JS disabled!" then I totally wonder what's the point, because almost no modern app or site works correctly without it.
What's more, the definition of "the web platform" in my book is simply HTML + CSS + Javascript, so those three, no more no less (and more fundamentally it's just the DOM, and generating/manipulating the DOM in whatever way we choose, with templates or with Javascript or with Web Assembly, or whichever way we want).
But if you follow the reasoning of the "non Javascripters" you might even say that only HTML is essential - so we would then argue that sites should work even with CSS disabled (if that were an option lol)
I develop JS-driven sites all the time, and have no problem visiting other JS-driven sites.
However, I do find it kind of tacky if a site requires JS and there is no content on the site whatsoever (i.e. a completely white or black page), without any noscript tag being used to tell the user to enable it.
I understand that, I also use the noscript tag to render a fallback but this simply states to activate Javascript in order to make it work
Totally understood. I was slightly out of context when I posted it. Good article though.