Prototype hosted on Google's servers
Good news! Google now offers a cached, compressed copy of Prototype on its high-speed content distribution network via the AJAX Libraries API.
You can either link to the source code directly:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
Or you can use Google’s API:
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">google.load("prototype", "1.6.0.2");</script>
More information is available from Google’s documentation.
When a specific version of Prototype is delivered to your browser, it will be cached for one year and served with the proper compression headers. That means that most users of sites which link to Google’s copy of Prototype will incur a ~30 KB download only once.
We typically encourage developers building applications with Prototype to concatenate all their JavaScript into a single file, and serve that file with the proper content expiration and compression settings. In cases where this is unfeasible, Google’s hosted version is an excellent alternative.
Special thanks to Dion Almaer and the team at Google for making this possible.
Sorry, comments are closed for this article.
Comments
Why is there no compressed (meaning minified, not gzipped) download?
Google serves minified versions where they are supported by the developer.
That said – Google tells the browser to cache the downloaded library for a year, so its really not going to matter – it will only get downloaded once. And if this gets popular there’s a good chance that it’s going to be already downloaded and cached before they even get to your website :-)
Cool!
I thought that, one day, major browsers like Firefox or IE could have included a local copy of major js frameworks on every client installation, but I find it a good initiative from Google to improve performance!
Wow, that’s the coolest thing I’ve seen this morning!
I took a look at it in Firebug. It’s lightweight and fast. 30kb on the first load in 300ms. 5ms thereafter from local cache.
I think it’s a good thing browsers don’t cache major js frameworks on every client installation. We’re moving to a world of REST and APIs and decentralization. Loose coupling. The last thing we want is another Microsoftian “driver library” with all the legacy issues that come with it.
The architecture of the Internet truly allows for a more powerful software paradigm. In any event, bandwidth is on it’s way to becoming a commodity. Our current bandwidth experience will one day be the floppy disk of the future – just a box of old DOS programs.
Hi.
I’ve been using http://rakaz.nl/item/make_your_pages_load_faster_by_combining_and_compressing_javascript_and_css_files for a while now (though slightly modified).
This code automatically deals with the library being updated.
I see Google has incorporated the version number into the URL. Nice.
What is the lead time between a new release/update of prototype and it being on Google?
Also, is having to change every script to take advantage of the new library really necessary?
Could there be a …
or a …
A nice idea, but I would have thought most people would have already got this covered in one way or another.
Regards,
Richard Quadling.
Hi.
There should have been link examples …
src=”http://ajax.googleapis.com/ajax/libs/prototype/latest/prototype.js”
or
src=”http://ajax.googleapis.com/ajax/libs/prototype/latest-beta/prototype.js”
Hi Sam,
i used ajax cascading dropdown example using prototype.js, it’s working fine on IE 7 but not on IE 6, pls suggest.
On second thoughts, Google’s doing a terrible job here:
1. The initial servings of Prototype often didn’t download in Safari or Firefox past the Ajax declarations. Scriptaculous also had partial download problems. Now I can’t get Prototype.js to download properly without adding a query string to override the caching, which itself provides most of the benefit.
2. The links on the Google Ajax Libraries page to “FAQ” and “Blog” in fact point to Google Search API or Google Feed API and there’s practically nothing about the Ajax Libraries API there.
3. The video on the same page links to a video about the Google Feed API.
4. There’s no clear link to the Google JS file to use when calling Google Load. Of course it’s there somewhere but the layout is poor.
5. Instead of wrapping the URIs to the various libraries served by the Google Ajax Library API, these are just written out. It’s maddening to have to copy/paste URIs. Really, surely Google of all people should be promoting “link love”?
In the end, very poor on Google’s part. Comes strongly unrecommended.
Rich web apps have arrived. Most Google products themselves (Maps, Reader, GMail) can’t be used without Javascript.
And Google are even pushing Gears as an alternative to Silverlight etc.
But when we want to use Javascript to hook on the fragment identifier and provide client-side navigation to speed things up for our users, Googlebot ignores us and we get the “design for your users, i.e. don’t rely on Javascript” mantra.
The only alternative is the <noscript>. This fails because everything gets indexed against one URI. And where we could help Googlebot out by providing a plain-text version (of the same content) with a proper link structure (mirroring the client-side fragment identifiers used), Google considers (what is really content negotation) to be cloaking and fails to proactively disambiguate the difference between “same content/different representation” and “different content”.
There. That’s what’s on my mind! :)