If you load jQuery as part of your first party bundle, sure. But if you load it from a 3rd party CDN, you can assume it will independently fail at some point. If you’re making something important, the proper resiliency practise would be to gracefully handle it.

Obviously if jQuery is critical to your site working at all there’s not much you can do, but for any dependencies that are not critical or only critical to a small portion of features, it’s a much better UX to degrade only those features.

But, we, as web-devs, know, KNOW, that blockers a) exist and b) are used by clients.

It's like missing a test case that covers 15% of your user base.

Is it 15%?

I have no idea. They don't show up in my analytics...

Looks, it's Friday, I kinda made that up. A system I operate has rate higher than that but a trusted associate has a site with numbers like 2%.

Check your own metrics. It's for sure not zero.

It’s a joke because ad blockers block the analytics they would show up on.

I mean, it's a joke-but-not-a-joke.

It's actually reasonable for sites to be able to estimate the proportion of their population who block their analytics by looking at say, the proportion of signups or conversions or sales or whatever that come from 'untracked' sessions. But that is confounded by the fact that the population who uses ad and script blockers is not necessarily similar in behavior to the population who don't.

If 2% of signups to my newsletter come from sessions that don't show up in google analytics, does that mean 2% of my site traffic is using an ad blocker, or are they actually 10% of my site traffic - but those users are just 5 times less likely to give me their email address?

Why not? Log analytics are a thing, you know ....