5 ms·

All 3rd party javascript is broken. It's simply a fact. 15 years into the Web, still nobody has learned to check their external references before using them.

All 3rd party javascript is broken. It's simply a fact. 15 years into the Web, still nobody has learned to check their external references before using them. Even google gets it wrong pretty much every single time. If you really need to use somebody else's script on your site, the only thing you can do to protect yourself is to also add global exception handling to the page. It would be nice if we could expect giant companies that publish Javascript APIs for a living to actually check that their Javascript works in most standard cases, but that's just not the way it works in the real world.

thorax 18y ago
Got any pointers to "gotchas" articles or guides for cross-site JS widgets/includes? If not, want to write one? I've been looking for some blog articles on this recently for our team.
- jasonkester 18y ago
  I actually almost wrote one today. Basically, if you're doing a JS API, you're likely going to end up with a pattern like: <script src="api.js"></script> <script> MyAPI.userID = 4000; MyAPI.Start(); </script> That's how most everybody does it, and it's guaranteed to throw ugly script errors any time a network error causes the .js file download to fail. It's really easy to work around though. Somewhere in that .js file, simply declare a variable, or better still a method that sniffs for DOM dependencies like "does this div that I need to function actually exist". So you end up with something looking like this instead: <script src="api.js"></script> <script> if (window.MyAPI && MyAPI.CheckDependencies()) { MyAPI.userID = 4000; MyAPI.Start(); } </script> That way, your thing will only run if it has fully loaded and has a reasonable chance of actually working. Here's an old article I wrote with some other ideas: http://www.expatsoftware.com/articles/2008/05/one-rule-of-dhtml-programming.html http://www.expatsoftware.com/articles/2008/05/one-rule-of-dh...
  - thorax 18y ago
    Great start there. Thanks a lot for the response. Some of our widgets actually do it the other way: <script> MyAPI_userID = 4000; MyAPI_something = 2; </script> <script src="api.js"></script> With the embed script itself doing what it needed to initialize things further.
  - ahoyhere 18y ago
    Oh hi. It's you! I read all of your blog a while back, maybe a year ago, when there was a long sabbatical. Most of the posts were about how to do the biz thing while all over the place, geographically, as I recall. I see you're back! But no more globe trotting posts? I'd love some updates to that part of your life, since I'm having to deal with such a situation myself.
    - jasonkester 18y ago
      Trotting around Venice, CA at the moment, after I got sorta ejected from the UK for coming and going too frequently. Lived in Basque country for a year, moved (unsuccessfully) to England. But yeah, I guess I haven't been writing too much about travel of late. This might help a bit: http://www.blogabond.com/jason http://www.blogabond.com/jason

thorax 18y ago

Got any pointers to "gotchas" articles or guides for cross-site JS widgets/includes? If not, want to write one? I've been looking for some blog articles on this recently for our team.

jasonkester 18y ago
I actually almost wrote one today. Basically, if you're doing a JS API, you're likely going to end up with a pattern like: <script src="api.js"></script> <script> MyAPI.userID = 4000; MyAPI.Start(); </script> That's how most everybody does it, and it's guaranteed to throw ugly script errors any time a network error causes the .js file download to fail. It's really easy to work around though. Somewhere in that .js file, simply declare a variable, or better still a method that sniffs for DOM dependencies like "does this div that I need to function actually exist". So you end up with something looking like this instead: <script src="api.js"></script> <script> if (window.MyAPI && MyAPI.CheckDependencies()) { MyAPI.userID = 4000; MyAPI.Start(); } </script> That way, your thing will only run if it has fully loaded and has a reasonable chance of actually working. Here's an old article I wrote with some other ideas: http://www.expatsoftware.com/articles/2008/05/one-rule-of-dhtml-programming.html http://www.expatsoftware.com/articles/2008/05/one-rule-of-dh...
- thorax 18y ago
  Great start there. Thanks a lot for the response. Some of our widgets actually do it the other way: <script> MyAPI_userID = 4000; MyAPI_something = 2; </script> <script src="api.js"></script> With the embed script itself doing what it needed to initialize things further.
- ahoyhere 18y ago
  Oh hi. It's you! I read all of your blog a while back, maybe a year ago, when there was a long sabbatical. Most of the posts were about how to do the biz thing while all over the place, geographically, as I recall. I see you're back! But no more globe trotting posts? I'd love some updates to that part of your life, since I'm having to deal with such a situation myself.
  - jasonkester 18y ago
    Trotting around Venice, CA at the moment, after I got sorta ejected from the UK for coming and going too frequently. Lived in Basque country for a year, moved (unsuccessfully) to England. But yeah, I guess I haven't been writing too much about travel of late. This might help a bit: http://www.blogabond.com/jason http://www.blogabond.com/jason