As for your app becoming reliant on Google's version of the framework, you can always download the JS file they've been serving and host it yourself. You can't get locked in that way.
This misses the point. I'm not concerned about where the file comes from. If breakage occurs with regard to where the download comes from, a few customers get annoyed while you fix it (or even better, you implemented caching and customers never know the difference). That's a normal and expected maintenance issue that you plan for.
What I'm really talking about is the content of the file. If Google fixes bugs or adds features and you don't realize it until your app has become dependent on Google-specific changes, it's not an easy thing to fix. This is a different problem than getting screwed over by ad providers.
Maybe one possible solution to my concerns would be to keep a table of sha1 sums of the version you want to depend on, and check them periodically (randomly select 1 of every 1000 visits to receive the checking code that reports back to your backend).
I just have an instinctive wariness of this kind of dependency, even if the cost of avoidance is a performance penalty.
It looks like with this, I'd need to request JQuery off Google's infrastructure and then all the other stuff off my own, so it's multiple requests where one used to do, and you don't get the benefit of compressing them together.
In the video they say that they used many of Steve Souders' techniques to speed up the deliver of the files since most web servers aren't properly optimized out of the box
Looks like Google missed the part in Souders' High Performance Web Site where he talked about using ETag to speed up sites. :P
curl -I http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js
HTTP/1.1 200 OK
Last-Modified: Mon, 26 May 2008 18:45:05 GMT
Content-Type: application/x-javascript
Expires: Wed, 27 May 2009 17:39:22 GMT
Date: Tue, 27 May 2008 17:39:22 GMT
Cache-Control: public, max-age=31536000
Content-Length: 55740
Server: GFE/1.3http://developer.yahoo.com/performance/rules.html#etags
"If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether. The Last-Modified header validates based on the component's timestamp. And removing the ETag reduces the size of the HTTP headers in both the response and subsequent requests."
http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB...
Basically, he suggests that every script tag have an option attribute called 'hash'. Whenever the browser downloads a script, it computes the hash and caches the script. For any further requests that specify that hash, the browser can used the cached copy instead of downloading a new one. The main benefit here is that everyone can continue hosting their own scripts, yet still take advantage of caching.
Brendan Eich (creator of JS) proposes a different solution:
http://weblogs.mozillazine.org/roadmap/archives/2008/04/popu...
In your script tags, you would specify both a local version (using the src attribute) and a canonical version (using a 'shared' attribute).
Brendan's concern about the hash solution is the poisoned message attack (http://th.informatik.uni-mannheim.de/People/lucks/HashCollis...). However, I'm not sure that applies here. I believe that you need to be able to generate both documents in order to easily find a collision. Anyone else know if that's true?