[RFC|Merged] Use Google's jQuery

[Oleg]

Moved into RFC forum, changed title to include the RFC prefix.

[VSE+]

"localhost" is incorrect for just about all live boards. I would suggest something along the lines of "included" or "bundled" copy instead of "localhost" and change the question to "Use the included/bundled copy of jQuery hosted on your server or use jQuery hosted by a third-party CDN", which is perhaps longer but more reflective of the actual option.

Note that the fallback option is going to be useless in cases where the browser never gets to it. Firefox will hang forever/infinitely loop in certain network conditions on an inline <script> tag like the one used for the cdn, never executing anything after it in the markup.

Agree about the naming, but we should call it whatever makes most sense though, I guess. To me that was "localhost". Anyhew, I changed some of the language used and updated the pull request.

But don't agree about the fallback. All the developers at html5boilerplate.com have really sussed it out and use it as the best practice for jQuery inclusion (except that theirs is a little simpler and also only HTML5 valid... this one is both HTML5 and XHTML valid). And of course, the fallback will only be needed if the CDN fails - which rarely ever actually happens. And even it does, there's also the likelihood that it's in ppl's browser's cache too.

[VSE+]

PS: So I just ran this test in firefox... Offline, so it was forced to go to the fallback. From what I see in firebug, it spent 1ms on the unavailable hosted CDN before moving forward and loading the local/default copy from the fallback.

[VSE+]

Thinking about Igor's point, I tend to agree that just a yes/no would be nicer for the ACP. But then the question is: which one do we pick? We can probably still have a config variable in the database (for our future about:config like config editor) that stores the actual CDN URL or something along those lines. So someone who really wants a different CDN, can pick a different one through the db.

What do you think?

You don't think this is simple enough? I figure anybody who will change this, should already know why they are changing it, and thus, will be familiar with the whole concept of hosting jQuery from a CDN. So to dumb it down for those who know nothing about it only limits its functionality for those who actually want this sort of feature.

But also, based on prior discussions here about this whole concept, I think we need to give the user options for these reasons/fears/concerns/conspiracy theories:

•The best option to go with if we only choose 1 is the Google CDN. It is the proven standard when hosting jQuery via CDN. But people have asked, will Google hosted CDN content be available in China??? Google has pulled out of China so...
•Microsoft CDN content is available in China, but Micorsoft is not as commonly used or proven as Google is when it comes to hosting jQuery.
•Hosting from jQuery themselves is probably the least secure, reliable option. But it is not going to be bogged down by the politics that say, keep Google out of China
•Different parts of the world have different performance stats from these CDNs. A forum based in Europe and with mostly European audience can pick the CDN that is fastest in Europe (http://royal.pingdom.com/2010/05/11/cdn ... cast-cdns/), which may be different for a North American board/audience.

But I leave it up to ya'll... If it has to be a 1-horse race, I vote for Google (it's the most widely used by a landslide, and thus, most likely to already be in your user's browser caches)

More reading:
http://www.jquerycdn.net/which-jquery-cdn/
http://encosia.com/6953-reasons-why-i-s ... ry-for-me/

[Oleg]

As I said, you need to have certain conditions. Try loading a script from a site which blackholes all traffic sent to it, or that accepts a request and sleeps for 1 hour. On freebsd, https://bugzilla.mozilla.org/show_bug.cgi?id=684758 causes firefox 3.x-6.x to burn 100% cpu indefinitely when it tries to connect to a port where nothing is listening.

[callumacrae]

Note that the fallback option is going to be useless in cases where the browser never gets to it. Firefox will hang forever/infinitely loop in certain network conditions on an inline <script> tag like the one used for the cdn, never executing anything after it in the markup.

That's the generally accepted way of doing it. That's a bug in Firefox, not this code (and is there anything that would work around it, short of a setTimeout on the line above?)

[sooskriszta]

You don't think this is simple enough? I figure anybody who will change this, should already know why they are changing it, and thus, will be familiar with the whole concept of hosting jQuery from a CDN.

I agree with you. As long as this is in the System tabs and disabled by default, a dropdown is good and simple enough...no need to further dumb it down.

[sooskriszta]

•Hosting from jQuery themselves is probably the least secure, reliable option. But it is not going to be bogged down by the politics that say, keep Google out of China

I think jQuery themselves host on Google

[sooskriszta]

If it has to be a 1-horse race, I vote for Google

+1

[callumacrae]

jQuery use the google CDN, and then themselves as a fallback. They don't like people using them as a CDN.

(iirc)