5 ms·

Not malicious but sloppy.

by sanxiyn 6y ago

Spivak 6y ago
I mean kinda. I wouldn’t bother to check if jQuery was defined if I explicitly included it in a script tag.
- edoceo 6y ago
  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.
  - jameshart 6y ago
    Is it 15%? I have no idea. They don't show up in my analytics...
    - edoceo 6y ago
      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.
      - Spivak 6y ago
        It’s a joke because ad blockers block the analytics they would show up on.
        jameshart 6y ago
        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?
    - ddalex 6y ago
      Why not? Log analytics are a thing, you know ....
- pushrax 6y ago
  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.
viraptor 6y ago
It's not even sloppy. When people write code with dependency X, they don't check if X is available before every call. The website works as designed. The user decided to change the environment behaviour in an unexpected way.
- jasonkester 6y ago
  It's not even sloppy 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”); For exactly this reason: because often all you get is what you sent down the wire yourself. You still need to work with that.
underwater 6y ago
To be honest the web is a pretty hostile environment to program in. 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.
- bikeshaving 6y ago
  > 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. 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.
  - underwater 6y ago
    React does make this worse, but even with vanilla JavaScript, having a third party make arbitrary changes to the DOM means that there may be no way to safetly perform certain operations. 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.
- banana_giraffe 6y ago
  > Or users regularly injected code into your iOS at runtime to remove or change views 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.

Not malicious but sloppy.

Spivak 6y ago

I mean kinda. I wouldn’t bother to check if jQuery was defined if I explicitly included it in a script tag.

edoceo 6y ago
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.
- jameshart 6y ago
  Is it 15%? I have no idea. They don't show up in my analytics...
  - edoceo 6y ago
    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.
    - Spivak 6y ago
      It’s a joke because ad blockers block the analytics they would show up on.
      - jameshart 6y ago
        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?
  - ddalex 6y ago
    Why not? Log analytics are a thing, you know ....
pushrax 6y ago
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.

viraptor 6y ago

It's not even sloppy. When people write code with dependency X, they don't check if X is available before every call. The website works as designed. The user decided to change the environment behaviour in an unexpected way.

jasonkester 6y ago
It's not even sloppy 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”); For exactly this reason: because often all you get is what you sent down the wire yourself. You still need to work with that.

underwater 6y ago

To be honest the web is a pretty hostile environment to program in. 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.

bikeshaving 6y ago
> 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. 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.
- underwater 6y ago
  React does make this worse, but even with vanilla JavaScript, having a third party make arbitrary changes to the DOM means that there may be no way to safetly perform certain operations. 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.
banana_giraffe 6y ago
> Or users regularly injected code into your iOS at runtime to remove or change views 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.