Don't Back Down

Thanks to Jesse, I decided to read up on Google's Ajax Libraries API, a "content distribution network and loading architecture for the most popular open source JavaScript libraries" (their words). In simpler terms, Google will host some of the most common JavaScript libraries for you, such as jQuery, prototype, script.aculo.us and MooTools (my words).

The immediate benefit is not having to host it myself. That's cool. I don't use a lot of JavaScript, but as you probably know, I'm a fan of offloading things to other people when it can save me the hassle of doing it myself - FeedBurner (now another Google property) is one of the most famous examples of this. But I'm not sure if JavaScript will work in this arena. First and foremost, because I use so little of it, I'm not sure if it really matters. Only 30K or so on my individual archives (such as this one). Even if every visitor I had to the site downloaded the pages fresh, instead of caching them, and every page that I had had those pages - a virtual impossibility, since they don't use themselves - we'd only be talking about 1GB per month or so. That's hardly worth the effort for me - though it may be for you. But what about the user experience? Maybe that is worth it.

According to Ajaxian, there are two ways to invoke the files. You can either call the files directly through a standard SCRIPT tag, like most people do, or you can call them as a google.load parameter. I'll take a look at both. First, the standard call, looking at MooTools (since that's what I use here). It should look something like this for the compressed version:

<script src="http://ajax.googleapis.com/ajax/libs/mootools/1.11/mootools-yui-compressed.js">
</script>

Unfortunately, though it seemed to load correctly, I couldn't get it to work with my installed version of Slimbox. I also couldn't get the uncompressed version to work - both kept getting errors. So I decided that I'd try the google.load method instead. To try this, you have to first call the Google jsapi library, then the google.load function with the appropriate parameters. For MooTools, it should look like this:

<script src="http://www.google.com/jsapi"></script>
<script>
  // Load MooTools
  google.load('mootools', '1.11');
</script>

The advantage to this method is twofold: First, it worked, and second, if you decide to change libraries, all you have to do is change the parameters, you don't have to go hunting down the new URL.

As to load times, you're actually loading two scripts - the jsapi script and the mootools script (the compressed version from above). So that is two connections, rather than one. In my experience, I found that the load time was actually 2-3 times slower than loading from my own personal shared server, even though it was coming from Google, and my version of the compressed file was a couple of K larger than Google's. This, even after the file had loaded and (presumably) cached. So for me, since the bandwidth doesn't matter much, isn't going to matter.

One other issue that may be nice to implement is the ability to pull the latest stable verison of the library. Obviously this could cause some problems when the latest version breaks compatibility - but there are people who like to live on the edge. For them, it would be nice if you could pass a parameter like 'stable' into the google.load function and get whatever the last version is, so that you don't have to keep in mind a particular version number.

If you need to find your version number or a URL or something, Google provides a helpful cross-reference for finding out the various options that are offered.

The problem with compatibility when loading directly? I have no idea. It seems that the compressed file was being loaded when called directly, but when called via the google.load, it worked - so I'm not sure. I would have said that perhaps a module wasn't there. But I didn't care to bother with it, so I just went back to my own local file and it seems to be running just fine.