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.
> 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.
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.
> 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.
Well, that's just what you get for abusing a document viewing platform into being a programming environment. The Web was never supposed to be an application platform; it did well what it was designed for, which somewhat implies the ability of the user to have the final say over how the content should be displayed.
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.
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.
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.
> 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.
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.
> 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.
Well, that's just what you get for abusing a document viewing platform into being a programming environment. The Web was never supposed to be an application platform; it did well what it was designed for, which somewhat implies the ability of the user to have the final say over how the content should be displayed.
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.
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.
For exactly this reason: because often all you get is what you sent down the wire yourself. You still need to work with that.
I mean kinda. I wouldn’t bother to check if jQuery was defined if I explicitly included it in a script tag.
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...
4 replies →