[1] https://developers.google.com/analytics/devguides/collection...
It's like missing a test case that covers 15% of your user base.
I have no idea. They don't show up in my analytics...
Check your own metrics. It's for sure not zero.
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?
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.
It’s the definition of sloppy. Rule One of Javascript is that you check every 3rd party dependency before every call.
window.ga && ga(“user likes socks”);
Imagine if calling into a library randomly failed in Python. Or random apps directly inserted data into your SQLite database. Or users regularly injected code into your iOS at runtime to remove or change views.
One classic example we ran into was DOM that we'd just rendered suddenly had a different structure because Google Translate would insert new DOM nodes. So after a.appendChild(b); b.parentNode would be some random value instead of a. As a coder that's hard, you need some certainty to build on top of.
Experienced devs can develop intuition about stuff that breaks. But it's hard to be exhaustive. And there isn't a great deal of tooling available for fuzz testing this kind of stuff.
Gosh, this continues to be one of the problems I have with all of the major frameworks. Rather than assuming the DOM is a mutable, shared resource like it actually is, they treat unexpected DOM changes as undefined behavior, and will usually break at the slightest attempts by browsers or extensions to help the user. The Google Translate issue is still largely unsolved, and I’m always frustrated whenever I attempt to translate a blog post on development from Chinese and find out that it’s not working because they’ve decided to render in client-side with React.
Expecting every website developer to code defensively for every single operation is unsustainable. A better solution might be to just build APIs for common cases; like creating new nodes that are anchored to existing DOM nodes.
That used to be more of a thing. A big iOS app I was indirectly involved in eventually added jailbreak detection. Not because they wanted to block it, but to log it so they could track down some fun bugs caused by random tweaks that changed the UI in impressively hacky ways.