AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

This is really cool, but I'm not sure I'd use it because of the plugin issue. Usually, I don't just use JQuery - I use JQuery, plus a few JQuery plugins, plus JQuery UI, plus some custom JavaScript files that are built off this. To deploy them, I concatenate them all together in dependency order, minify the whole thing, and GZip it. That saves HTTP requests, and multiple files with the same coding standards tend to compress <i>very</i> well. (JQuery + Dimensions + Dropshadow + Corner = 20504 bytes when compressed together, vs. 21919 bytes when compressed separately.)<p>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.

Related to this, people might want to take a look at Doug Crockford's suggestion:<p><a href="http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=789" rel="nofollow">http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB...</a><p>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.<p>Brendan Eich (creator of JS) proposes a different solution:<p><a href="http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html" rel="nofollow">http://weblogs.mozillazine.org/roadmap/archives/2008/04/popu...</a><p>In your script tags, you would specify both a local version (using the src attribute) and a canonical version (using a 'shared' attribute).<p>Brendan's concern about the hash solution is the poisoned message attack (<a href="http://th.informatik.uni-mannheim.de/People/lucks/HashCollisions/" rel="nofollow">http://th.informatik.uni-mannheim.de/People/lucks/HashCollis...</a>). 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?

I still think I'd prefer to host them myself. When I used YUI style sheets hosted on Yahoo's servers they always took longer to load than local files. Also, Google ads are always the slowest item in a page to load. Until these libraries are embedded in the browser I don't see much benefit.

<i>edit</i> Nevermind, nothing to see here <i>edit</i><p>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<p>Looks like Google missed the part in Souders' High Performance Web Site where he talked about using ETag to speed up sites. :P<p><pre><code> 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.3</code></pre>

It's a neat idea, but I can't imagine using it. Do you really, really trust Google with your business? What happens when google decides to "fix" something in one of those frameworks that the upstream developers disagree with? Even worse, what happens when your app is irreconcilably broken because of something that happened at Google? Worse still, what happens when your app somehow becomes reliant on Google's version of the framework(s), and you don't realize it until it would be too expensive to unhook yourself from Google?

Excellent. With pipelining browsers this will speed things up even on the first hit

Thank you, this is useful to me.