Comment by Jason Knight on "In 2018, does SSR still provide an advantage over CSR for: (1) SEO, (2) performance?"

I still say CSR is bullshit for one simple reason; tis a walking talking WCAG violation which means you are flipping the bird at users with accessibility needs, often flipping the bird at users who intentionally block JavaScript due to bandwidth concerns, and to be BRUTALLY FRANK?

If you are seeing performance benefits from its use, you likely don't know enough about HTML, CSS, or JavaScript to be outputting a damned thing to the client in the first bloody place!

Which is why I'm no fan of GARBAGE like React when it comes to web deployment. (IF I were to use it, it would only be for native crapplets)

As the saying goes:

If you cannot make a fully functional website without JavaScript FIRST, you likely have zero business adding scripting to it!

Good scripting should enhance an already working page, NOT be the only means of providing base functionality.

To that end though, if your page relies on some scripttardery to load before the user can 'interact' with content then you have ZERO damned business making websites! That's why even as SSR "React" is incompetent asshat BULLSHIT!

Content of value, marked up semantically, targeted to specific media with CSS -- if you aren't outputting that first in a manner that works WITHOUT JavaScript, you aren't doing your uncle-huffing JOB as a web developer!

Which also means that if you are in a environment like healthcare, insurance, banking, government, and so forth, your scripttardery will also land your ass in COURT! See the US ADA and UK EQA laws, as well as most contracts in those industries demanding WCAG compliance.

.... and one of the biggest aspects of WCAG compliance is having pages work WITHOUT scripting client side!!!

Though of course, actually having semantic markup is something most developers have ZERO blasted clue how to do, just like all the other things the head-bobbing mouth-breathers are either ignorant of or outright scoff at like separation of presentation from content, progressive enhancement, graceful degradation, and so forth. Hence why so many know-nothings praise bootcrap like it was the second coming ignoring how they piss all over their markup with presentational classes defeating EVERY bit of web development progress made since 4 Strict was introduced -- hence most such dipshits vomiting up 60 to 200k of markup to do 6 to 16k's JOB! Hence the mentally enfeebled wasting 200k to half a megabyte of CSS on doing 24-32k's job! Hence the bloated agonizingly useless megabytes of scripting on websites that have NO LEGITIMATE REASON TO EVEN HAVE JAVASCRIPT ON THEM!!!

Then the scripting junkies have the unmitigated gall to claim their bloated slow loading train wreck improves the user experience? BULLCOOKIES!

Though it's real fun watching the ignorant half-assed bull go bits-up face-down when they go to deploy on a server that's sending CSP headers. <style>, style="", onevent="", <script>var scriptingHere=""</script>, href="javascript:", CSSStyleSheet.insertRule(), eval, pulling frameworks from other servers... WHAT THE?!? Sorry, they no longer exists thanks to a HTTP header we're using, your code is shit, refactor.

CSP doesn't prevent client side rendering, even with some of the strictest policies which still allow javascript to be functional.

I know this because I've been working on this with Vue the past few weeks.

Sorry to say but, time is changing & " If you cannot make a fully functional website without JavaScript FIRST, you likely have zero business adding scripting to it! " doesn't makes any sense now.

Joe Gaspar No, it doesn't prevent scripting, but it DOES prevent all those things I listed that scripting jockeys and people ignorant of how to use HTML properly get wood over. You want scripting, you include it from an external file or you don't use it at all.

Atul Sharma It makes perfect sense if you want to keep battery use low, have pages that work for users with accessibility needs, NEED to meet WCAG or similar accessibility minimums so you don't land in COURT, or even have the most basic understanding of progressive enhancement.

I'm not saying you can't enhance the page with scripting, but if you don't have scripting off fallbacks you are telling large swaths of users to go f*** themselves!

Even Hashnode is guilty of this, I know a few developers who might be interested in this place, but with it being scripting only they sure as shine-ola aren't going to visit here. I only tolerate it because I'm reasonably certain Ghostery and the stack of ad-blockers and tracking blockers I have in place will tell anything I distrust in JS to sod off.

People visit websites for the CONTENT, not the goofy half-assed art or silly bandwidth wasting effort wasting scripted junk you hang around it!

The really pathetic part about things like SSR being it is most often MORE work and less useful -- but again that's like front-end frameworks in that they don't make you work smarter, they just make you work harder and/or prey on your ignorance of HTML, CSS, and JavaScript! Hence how MOST of the people who delude themselves into thinking "javaScript only" share the same ignorant nonsense as Bootcrap/w3.css/framework users of vomiting up CtCR's of 10:1 or higher (Code to Content Ratio) resulting in 60k of markup or 70k of semi-markup AJAX'd in requiring half a megabyte or more of scripting to even function, doing the job of 16k or less of flat markup!

Which is why I'll never understand the claims made about these types of systems as how is writing two to ten times the code "easier"? How in blazes does it make you "more productive"? How does it help the visitor actually get to the CONTENT?!? All the claims of how wonderful this rubbish is holds water like a sieve!

I've never seen ANYTHING done with this garbage that if you used it on a bank, or government agency, or in healthcare wouldn't result in either court fines or civil lawsuits under laws like the US ADA or UK EQA. Scripting only functionality is an INSTANT violation!!! ...and that's before we talk all the other ignorant failings people ignorant enough to use such methodology by choice seem to load up on.

But that typically means nothing to the know-nothing's who get a raging chodo over hot-and-trendy gee ain't it neat hoodoo-voodoo; amounting to nothing more than flash over substance or stroking their own ... ego -- Let's say ego. I mean something else -- all in the name of "looksiez ats whut eye canz doos wit muh scripz! ...all with zero care how many users they're PISSING OFF in the process.

Nope, try again. CSP doesn't prevent securely including style or script tags, nor does it prevent loading resources from other white listed locations. The former can be white listed via either content hashes or nonces and strict-dynamic. The latter can be white listed by specifying the host name in script-src, style-src, or whateverelsethatapplies-src.

Joe Gaspar Yes, whitelisted, as in they are blocked by default -- WHY they are blocked by default is the important part and if you have to whitelist something, you are BYPASSING THE ENTIRE HUFFING REASON CSP EXISTS IN THE FIRST PLACE!!!

Basically, making it the equivalent in relation to regular JS as 4 tranny was to HTML 3.2 -- 100% grade A derpitude. If you're going to do that (white-listing things that were blocked on purpose), you might as well not even bother sending CSP headers in the first bloody place! Same thing as the mental midgetry of using scripting to replicate target="" in a 4 strict document -- COMPLETELY MISSING THE POINT!!! (that shoving a new window down the user's gullet just pisses them off, they want a new window let them middle-click or ctrl+click)

Just like with (the mind-numbingly idiotic halfwit dumbass) 4 Tranny (and a goodly portion of HTML 5 when compared to 4 Strict), the white-listing exists so you can mix crappy old stuff that you SHOULD NOT BE USING IN THE FIRST DAMNED PLACE (like style="", <style>, onevent, etc, etc) in with the new, and it has no business being used on new documents.

style="" should only be used when the style is helping convey meaning -- such as the value of bar graph elements or font-size in a tag-cloud -- <style> has ZERO legitimate reason to even EXIST in the bloody specification, and realistically now that we have data- attributes there is no reason for <script> to have scripting inlined inside it. Don't even get me started on the halfwitted code-bloat asshattery of the onevent attributes! If you "need" those you likely don't know enough about HTML, CSS, or JavaScript to be building websites.

But what do I know? I think <style>, target="", all the onEvent attributes, <article>, <section>, <nav>, <aside>, <header>, <footer>, <main>, <audio>, <video>, aria roles, and a slew of other things should be stricken from HTML entirely for either being pointlessly redundant, making the specification twice as difficult as it needs to be, outright bad practice, and just pissing on every bit of progress HTML 4 Strict tried to give us.

When people can't even use H1..H6 or HR properly, throwing more tags at it for people to just blindly use without understanding the specification is NOT the answer.

You honestly have no clue what you're talking about.

Best answer EVER! Loved it!

Search Hashnode