Comment by mvdtnz
No one is browsing the internet without JS today (within margin of error). Whether or not this "should" be the case, it is.
No one is browsing the internet without JS today (within margin of error). Whether or not this "should" be the case, it is.
> 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?
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)
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.
From a business perspective you can go further: the people who are browsing the internet without JS are people who are going to cost you more to support than they'll ever bring you in revenue. Just like trying to support Linux gamers, excluding them is a net positive.
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).