[spartanatreyu]

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).

[handoflixue]

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

[justsomehnguy]

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.

[spartanatreyu]

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)

[lmm]

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

[spartanatreyu]

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]

Isn't that exactly the opposite of the "progressive enhancement" philosophy anti-Javascript people tend to claim to subscribe to?

[spartanatreyu]

How?

It doesn't have anything to do with progressive enhancement.

[lmm]

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