Google's CDN hosted jQuery 1.5 is down (Fixed after 40 min) | Hacker News Reader

Google's CDN hosted jQuery 1.5 is down (Fixed after 40 min)

ajax.googleapis.com

12 pointsakamaka28 comments

Hi,

Yes, it's being fixed and the update is being pushed out as we speak. (It should already be back up for some.)

Basically, we broke the alias from 1.5 to the latest version when pushing out 1.5.2. We caught it quickly, but not fast enough.

These URLs should all work now:

http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.j...

http://ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min...

http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min...

And now:

http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min...

Very sorry about the downtime.

-DeWitt

It's nice to know that you guys make mistakes too. Thanks.

For reference, these exist:

http://ajax.googleapis.com/ajax/libs/jquery/1.5.0/jquery.min...

http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min...

http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.j... (loads 1.4.4)

http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.js (the non-minified version of the link that's down. version is 1.5.2)

My guess would be something went wrong in rolling out v1.5.2 (since the minified version is 404ing but the regular version isn't). Of course, shouldn't your application be specifying a specific version of jQuery anyway, so that you control when the version changes?

Edit: Apparently 1.5.1 is still the latest release, according to the docs (http://code.google.com/apis/libraries/devguide.html#jquery)

Edit 2: The non-minified version still works, and it's returning 1.5.2.

Ah, so perhaps nobody should have been pointing to 1.5 (vs. 1.5.0) to begin with?

Edit: The docs mention only these specific version numbers: 1.2.3, 1.2.6, 1.3.0, 1.3.1, 1.3.2, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1

Well, yes and no. Google does specifically allow that behavior as part of their versioning policy (http://code.google.com/apis/libraries/devguide.html#versioni...). However, in a production environment, you really shouldn't be automatically loading the latest release of jQuery; what happens if there's a regression that affects your application's performance?

Regardless, I don't think that URL should be down.

That's very good to know. I had wrongly assumed 1.5 was and always would be 1.5.0.

Consider it anecdotal, but I've personally never been burned on any jQuery minor point releases. Going from 1.3 to 1.4 and 1.5 has always been cause to revisit my code, but generally, minor point releases have always improved things for me.

You lose almost all of the caching benefit when you use the "latest" version references, like 1.5. They're (necessarily) served with a very short expires header, as compared to the specific versions' +1 year.

How short is the header? While 1 year+ is nice, if 1.5.x is served with, say, a 24 hour expiration header, you can still get a lot of cache benefit if the user visits other sites that use jQuery that day.

One hour, I believe. Also keep in mind that other sites have to be using the 1.5 URL as well.

That's a very valid point that I hadn't considered.

I'd be curious to see how many people use the latest vs. the specific versions. Excluding the shorter cache on latest, in theory at least, you get the greatest cache benefit from whichever is the most linked-to version, yes?

E.g., if 1.5.1 is 300% more popular than 1.5.2 at a given point in time, then you're far more likely to be primed for any given user, yes?

There's danger in trying to out-think other sites, holding back on upgrades with the expectation that everyone else will do the same. If everyone did that, no one would ever upgrade at all.

On the contrary, I think that the sites which matter (those with high traffic and broad reach, which are also the most actively maintained) will probably upgrade fairly quickly.

This is why I host my own. Cost of doing business.

Isn't using Google CDN (quite possibly cached by user) with a fallback to a local copy the best of both worlds?

Why not fallback? That way you may get caching for first time users.

See HTML5 Boilerplate for an example of this.

It would be really cool to see how many websites failed because of this. Mashing up the amount of caching that actually goes on would be a cool metric to further improve CDN's with, anyone agree?

How does it make sense for google to pay for the hosting for this stuff?

Or google charts...I'm building a product that uses this pretty heavily right now, but it seems too good to be true. Generating those graphs for me is really nice, but the bandwidth and CPU cycles that I'm using aren't free (for google), what's their upside?

Cool, google, and thanks, but how does this make financial sense for you?

Not everything a company does has to bring in revenue (make financial sense).

But how do they justify this to their shareholders?

This is literally the type of stuff I daydream about... "Here, I've got all this computing infrastructure, isn't it cool? Tell you what, use it for free!"

That's awesome. I guess I was kindof asking if I was missing the point or something. Are there really people at google who are saying "Listen, boss, I'm going to need $money to build google font library. I'm going to need $foo engineers, and $bar resources, but we should do this because it would be fun!"

And their boss goes "huh, cool! Yeah, here is some money!"

Note that Microsoft also considers it worthwhile: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.2.js

It makes it easier for people to build web applications instead of Windows applications. If people build web apps, then Google has a shot at making some money off of it if the designer wants to monetize with ads or google checkout.

Yes, Google's business is on the web, and they've made it their mission to make the web as fast as possible.

If the web doesn't speed up, more users will move to closed ecosystems like the iPhone App Store.

Other projects are motivated by this are Google Chrome (and the open source around it) and Google Page Speed, for example.

Google Charts gives Google all your chart data in textual form -- if you generated chart images with another app they wouldn't be able to crawl it.

It says pretty specifically that they don't store or index the data in the google charts terms of service.

That data is still a URL in your page - the axis titles at the very least will be crawled.

My question would rather be "how does it make sense to rely on an outside source for this stuff?". Really, website developers are introducing another, completely unnecessary point of failure if they hotlink an external jQuery version.

It's not such a huge file either, I can't imagine what benefits people think this has. Is it so the first page loads a fraction of a second faster (maybe)?

It works now.

Hurray!

Reply on news.ycombinator.com