

Google Analytics JavaScript is Broken - anuraggoel
http://www.seomoz.org/ugc/google-analytics-javascript-is-broken

======
jasonkester
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
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
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-
dh...](http://www.expatsoftware.com/articles/2008/05/one-rule-of-dhtml-
programming.html)

~~~
ahoyhere
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
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>

------
eli
sounds more like your firewall filtering is broken.

~~~
DenisM
When I read to the end I found that author proposes a mechanism that is far
less convoluted than google's and devoid of this similar problems.

It's better to have less code in your page and more code in google's script -
that way they can patch it without me getting involved. As it is now they
added the try/catch block (really helps if users run ad-block or some such)
but most web admins have not updated their stuff.

~~~
eli
Though he accomplished it by altering the requirements. His solution does not
work seamlessly with HTTPS sites -- it requires a server-side changes to the
code. That's a pretty big issue for a script that's supposed to "just work."

~~~
DenisM
But it doesn't "just work" - it breaks it the face of some firewalls and pops
an exception if user has adblock. I actually had users complaining about the
latter, this is not a theoretical problem (I fixed it with try/catch myself,
but it should not have been a problem to start with and demonstrates
brittleness of google analytics).

In other words it's a tradeoff between http/https transparency and odd errors
on user's end. Pick your poison. :-)

