4 ms·

This is the wrong way of looking at it. Making a website's basic functionality work without JS isn't just for the random users who switch off their browser's J

This is the wrong way of looking at it. Making a website's basic functionality work without JS isn't just for the random users who switch off their browser's JS runtime. It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file).

lmm 11mo ago
Then why does that same logic not apply to the CSS file?
- spartanatreyu 11mo ago
  I mentioned that in my other comment. When CSS doesn't load, it's immediately apparent and the user knows they need to reload the page.
  - lmm 11mo ago
    Isn't that exactly the opposite of the "progressive enhancement" philosophy anti-Javascript people tend to claim to subscribe to?
    - spartanatreyu 11mo ago
      How? It doesn't have anything to do with progressive enhancement.
      - lmm 11mo ago
        > How You're saying that when the enhancement doesn't work, it's desirable that "it's immediately apparent and the user knows they need to reload the page". That's the opposite of what progressive enhancement people normally argue for.
handoflixue 11mo ago
> It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file). Does that really apply when the javascript is only ~2kb?
- spartanatreyu 11mo ago
  Yes, any request can get stuck at any time. That is what's happening any time you've seen a website that randomly decides to load without styles, or with a missing image. The good thing is that it's very apparent when that happens and you can just reload the page. But it's not immediately obvious when it happens with a JS file. That's half the reason why you shouldn't re-implement css features in a js file. (the other half is performance)
- justsomehnguy 11mo ago
  Do the end user should troubleshoot if that was a network dropout, some browser incompatibility or just a crappy code by a crappy coder? > the javascript is only ~2kb? It can be even 200Mb if it's not loaded properly and now a website doesn't even function.

lmm 11mo ago

Then why does that same logic not apply to the CSS file?

spartanatreyu 11mo ago
I mentioned that in my other comment. When CSS doesn't load, it's immediately apparent and the user knows they need to reload the page.
- lmm 11mo ago
  Isn't that exactly the opposite of the "progressive enhancement" philosophy anti-Javascript people tend to claim to subscribe to?
  - spartanatreyu 11mo ago
    How? It doesn't have anything to do with progressive enhancement.
    - lmm 11mo ago
      > How You're saying that when the enhancement doesn't work, it's desirable that "it's immediately apparent and the user knows they need to reload the page". That's the opposite of what progressive enhancement people normally argue for.

handoflixue 11mo ago

> It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file). Does that really apply when the javascript is only ~2kb?

spartanatreyu 11mo ago
Yes, any request can get stuck at any time. That is what's happening any time you've seen a website that randomly decides to load without styles, or with a missing image. The good thing is that it's very apparent when that happens and you can just reload the page. But it's not immediately obvious when it happens with a JS file. That's half the reason why you shouldn't re-implement css features in a js file. (the other half is performance)
justsomehnguy 11mo ago
Do the end user should troubleshoot if that was a network dropout, some browser incompatibility or just a crappy code by a crappy coder? > the javascript is only ~2kb? It can be even 200Mb if it's not loaded properly and now a website doesn't even function.