Comments on: google.load(): Utilize Google’s AJAX Libraries API

By: Josh Stauffer

Josh Stauffer — Fri, 05 Feb 2010 23:00:51 +0000

I recently started using google.load and for jquery and jquery ui. I think it is cool that they offer this.

By: Thomas

Thomas — Thu, 28 Jan 2010 09:11:36 +0000

Wouldnt it be better to just use google’s Closure Compiler(http://code.google.com/closure/compiler/) ?

By: Andrew Benton

Andrew Benton — Sat, 03 Oct 2009 02:51:32 +0000

@V1:

If you read the google pagespeed docs (http://code.google.com/speed/page-speed/docs/rtt.html) about parallelizing downloads you might actually be saving a little time. Plus the Google server’s IP will likely be cached by any ISP and even better, Google’s hosted script will likely be cached by the browser more often than yours will, so the DNS lookup and extra request most likely won’t actually happen.

By: Adriaan

Adriaan — Wed, 25 Feb 2009 16:26:23 +0000

Sending them through a “shrink” functionality every time would not only fail in relieving all of the items above, but it would hurt response time as it would put more stress on the server. Avoid that at all costs.

That’s true, but not if you implement a caching solution…then it’ll be much better. Ed Elliot has a nice post about this topic, and I use a solution based on some of his ideas, which works really great.

By: Live Web Studio

Live Web Studio — Thu, 12 Feb 2009 17:31:43 +0000

cloud computing is the feature, like mentioned in the first by David – the same file is served for everyone ! and if u wondering if the old versions remain on servers, the answer is YES ! so u dont need to manual update the direct link to the lib.

By: Jan Komzák

Jan Komzák — Wed, 28 Jan 2009 05:46:23 +0000

I think, that this solution is good, if you have restrictive data transfer on your site (shared hosting, …), but as @Anton says, i prefer having theese files at my own control.

It doesn’t mean that I’m afraid of Google, but there is no warranty that another day, there will be some other content than you expected :) In case of hosting these file on your host, it is minimal chance to scratch that file transfer.

And about the size and caching: there is JSmin, YUI compressor and so on, so at the case of MooTools it’s about 100KB for fullstack (core and more) code minified by YUI compressor.

I applaud Google for this initiative, and I’m sure that there are a lot of people who will use this, but I didn’t see some pros for this solution.

By: Ryan

Ryan — Wed, 28 Jan 2009 05:40:19 +0000

We have begun using a script called Combine that we rolled into our framework. It combines all the files and gzips them, stores that file on your server. Then it uses some nice caching that caches the file locally as well and forces a new version if you’ve changed anything. I also added in a whitespace stripping function but it didn’t save much over much since gzip does a lot of that itself.

Here is a post I did on it a while back:
http://blueprint.intereactive.net/compressing-javascript-part-1/

still yet to get all the post written that shows the benchmarks.

By: Anton

Anton — Sun, 25 Jan 2009 19:17:00 +0000

@Bryan J Swift: I do agree, it is a cool technique to get the latest version of the framework. However, I prefer to keep control of the framework versions just in case anything big changes.

By: V1

V1 — Sat, 24 Jan 2009 21:04:33 +0000

Yes its a nice technique, but I still prefer to host the files my self, it gives me control about my files, if there is something wrong, its MY own fault. I had allot of problems with google analytic (It took long time to LOAD the files more than one second, and I cant accept that behavior on my sites especially if you depend on these files.)

Also another reason why i dislike this technique, it will cost you one extra HTTP request for the google that will load the file for you.. And an extra DNS lookup because you will link to google. So there are some side effects from using this technique. If you do not care about this.. Yeah sure, go ahead and use it.. But its not that hard to apply cache headers your self..

By: Tom

Tom — Sat, 24 Jan 2009 14:44:33 +0000

I’ve been thinking of using this before, but haven’t implemented it yet. One of the reasons is that you have to load the Mootools-more from your own server anyhow. So my technique to date has been to join both “core” and “more” to one file and minify it. This works OK, as that file doesn’t really ever change.

But, I would start using google.load (or rather link directly the the files on their servers) if it would be possible to load the “more”-package as well. Seeing how jQuery UI and script.aculo.us being in the repository so should Mootools-more.js also be.