Use Google's AJAX API

I second this request.

And the version selector idea is pretty neat! ;)

I'm not sure it's possible to take advantage of Google's AJAX API in Drupal 5 without hacking Drupal core. I got a proof of concept working in Drupal 6 though. Unfortunately, Google's AJAX API doesn't include the 1.2.4a version of jQuery that ships with the 6.x-1.0 version of the module. Google's site says "1.2.5 and 1.2.4 are not hosted due to their short and unstable lives in the wild."

The Google AJAX API wouldn't make a good wholesale replacement for the local jquery.js file, since someone might be using Drupal locally without being connected to the Internet. But it would be a nice optional feature. When I get some more time, I'll add an administrative page to my proof of concept, to allow admins the option of switching between the Google's AJAX API and the local jQuery file.

The admin interface could also provide the option to designate a specific version of jquery to be added, but I'm not sure if that's wise since each new version of jQuery has the potential to introduce new issues. Is the version included with a release of jQuery Update a matter of timing or are there specific testing considerations?

Here's a patch for the Drupal 6 version that mostly works, except that it doesn't take into account the jquery_update_get_version function. I believe that will require that the available versions be pre-populated instead. While the AJAX Libraries API allows you to load the latest 1.x version by specifying "1" in the URL, there is then no way for the jquery_update_get_version function to know the correct version number to return.

I'm going to rework the version field on the administration page to use a pre-populated select box instead of a textfield.

Here's a better patch that returns the correct version number via jquery_update_get_version. It required that the version number be specified via a select box when using the Google AJAX Libraries API.

An alternative might be to periodically download the Google AJAX Libraries API version of jQuery just as a client browser would, parse the file just like the local version, then maybe cache the version number. That's a half-baked idea at this point. I'm open to suggestions. It would be nice to have the flexibility to just specify the latest 1.x version of jQuery and let Google take care of keeping up-to-date.

This is interesting. Why is this preferable over having the file locally? It seems like this would incur a performance penalty on every page load unless you got the local caching thing you mentioned working.

The blog post that's referenced in the initial comment basically states that it's to prevent 40 different versions of fooJSLibrary.js being included all over your site. That's fairly irrelevant here; Drupal provides a centralized jquery.js that's used by all of its installed modules and themes.

Being able to load the latest 1.x compatible code sounds good on paper, but how do you propose handling the necessary replacement files for incompatible core JS files (for example, farbtastic.js is not compatible with 1.2.6)?

In terms of why it is preferable to having the file locally, the blog post from the initial comment goes on to mention additional benefits. I think the first three points listed (caching, gzip, and minification) may be moot with Drupal, but the last three seem to be beneficial.:

# The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
# The servers are fast
# By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!

Can you elaborate on why you think it would "incur a performance penalty on every page load" as it stands? Maybe I'm missing something.

As for the compatibility issues, I was afraid that might be a concern (see my question at the end of comment #2).

Can you elaborate on why you think it would "incur a performance penalty on every page load" as it stands? Maybe I'm missing something.

Well, because of this:

The benefits sound all well and good, but if googeapis.com is slow or times out (or the CDN hosting it, whatever), my entire site hangs until that file is pulled in. I see this fairly often on various sites pulling in AdSense ads via direct linking to Google's .js files. Unless AdSense doesn't do this CDN stuff, but it seems like it obviously would, or unless this is a fairly recent (within the past year or so) change, and I'm just not caught up to speed on things.

But yeah. Unless we can figure out a solution to the replacement of core JS files that are incompatible with later versions problem, I'm afraid this one's going to have to end up in the "won't fix" bucket. :(

I couldn't use this on some sites due to privacy restrictions. But I like the idea as an option; theoretically having google serve a js file is superior if there's a chance a user has already visited another site using the same file, and assuming google's cdn is on average faster than your own server. Btw re: #6, drupal doesn't gzip javascript, though it can easily be done in the apache config (mod_deflate).

Don't forget about javascript preprocessing. There is a performance penalty for for each added javascript file added to a page. When a browser finds an external javascript file it stops what it's doing to process it. This is because this file may change the page and needs to be processed before moving on. Since we already have a drupal.js loaded in the page and what ever other files we are likely going to have a larger page load time from separating jquery.js out of the preprocessed file.

In any case it seems not ready for prime time. Doesn't work with HTTPS: http://code.google.com/p/google-ajax-apis/issues/detail?id=39

And it doesn't even gzip encode! (at least not when I tested with curl --compressed --head http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js)

In looking into this I noticed that drupal_get_js() doesn't deal with js files that aren't local. It adds base_path() before it calls the path. That could cause issues. There is an issue open against D7 in an effort to fix this.

When #91250: JavaScript Patch #4: External Scripts gets into core we can add this to the D7 branch.

HTTPS cert errors have been fixed. Gzip is only sent to User Agents known to support Gzip, Firebug reports they are gzipped.

Looks to me like all the issues blocking this patch have been resolved. Any reason not to get this option into 6.x-2.x-dev release?

I suggest we also take advantage of jQuery UI library right here, while we are at it.

A blog post about why everyone should use googles hosted files.
http://encosia.com/2008/12/10/3-reasons-why-you-should-let-google-host-j...

This causes obvious problems with local file aggregation of JS files though, right...?

@NikLP: These external files must be made exempt of aggregation.

Making the files external is probably ok for development, but as Webchick rightly says, this means the site is then dependent on the 3rd party server, which has no SLA for delivering those files. As such, it's probably a better idea to just aggregate your required version in with the rest of the drupal stuff, surely?

No it is BAD idea to aggregate these libraries with everything else. Why would you do this? This adds nothing to what can be done already.

Google does not go down. The point of including libraries hosted by them use them as CDN for standard components.

Nothing to aggregate with anything here.

"Google does not go down"?? That's a joke. Massive parts of google went down just the other week for like two hours.

This is just adding request times, unless it can be proven that a) the host can be guaranteed and b) the parallelism thing is actually helpful in this context.

Google (or any other CDN) is less likely to go down than your site :)

In any case, that is a moot point. This feature is not for those who do not like 3rd party CDNs, but for those who see the value of having this option.

Let's table this debate unless you have any constructive suggestions.

This patch doesn't seem to work against the current 6.x-.2.x-dev, but I think it's worth integrating with the module (or making available to Drupal by other means). Is there any interest in including support for Google AJAX Libraries API? I'll be happy to provide a new patch.

Here's an updated patch against the current dev. Upon further thinking, I believe this would be more properly refactored into its own module which would add options to the performance page, but since this was already extant, I've supplied the updates here.

And here's an initial module that does exactly that - after all, this functionality isn't really a "jQuery Update" but a performance enhancement (in the eyes of some, at least). Maybe I'll get someone to create a project for this. I'm not a fan of CVS, so I'm not sure I'd like to be a maintainer...

Yes, I've been working in some sites which got millions of page views. Hosting jquery on Google CDN increase the performance a lot. Hosting file on CDN is definitely faster than your own site considering the server power so it's really a significant performance boost instead of penalty.

#525436: configuring jquery_update to use jquery via Google CDN? is a duplication of this

Can we get this thing committed and have as a configurable option?