Google To Host Ajax Libraries

ruphus13 writes "So, hosting and managing a ton of Ajax calls, even when working with mootools, dojo or scriptaculous, can be quite cumbersome, especially as they get updated, along with your code. In addition, several sites now use these libraries, and the end-user has to download the library each time. Google now will provide hosted versions of these libraries, so users can simply reference Google's hosted version. From the article, 'The thing is, what if multiple sites are using Prototype 1.6? Because browsers cache files according to their URL, there is no way for your browser to realize that it is downloading the same file multiple times. And thus, if you visit 30 sites that use Prototype, then your browser will download prototype.js 30 times. Today, Google announced a partial solution to this problem that seems obvious in retrospect: Google is now offering the "Google Ajax Libraries API," which allows sites to download five well-known Ajax libraries (Dojo, Prototype, Scriptaculous, Mootools, and jQuery) from Google. This will only work if many sites decide to use Google's copies of the JavaScript libraries; if only one site does so, then there will be no real speed improvement. There is, of course, something of a privacy violation here, in that Google will now be able to keep track of which users are entering various non-Google Web pages.' Will users adopt this, or is it easy enough to simply host an additional file?"

Comments

nothing new here

[Yurka]

The DTD files for the basic XML schemas had been hosted centrally at Netscape and w3.org since forever. No one cares or, indeed, notices (until they go down, that is).

Re:solution in search of a problem

[dalmaer]

I understand that people like to jump onto privacy, but there are a couple of things to think about here: - We have a privacy policy that you can check out - There isn't much information we can actually get here because: a) The goal is to have JavaScript files cached regularly, so as you go to other sites the browser will read the library from the cache and never have to hit Google! b) If we can get browsers to work with the system they can likewise do more optimistic caching which again means not having to go to Google c) The referrer data is just from the page itself that loaded the JavaScript. If you think about it, if you included prototype.js anyway then we could get that information via the spider... but it isn't of interest. We are a for profit company, but we also want to make the Web a better faster place, as that helps our business right there. The more people on the Web, the more people doing searches, and thus the better we can monetize. Hopefully as we continue to roll out services, we will continue to prove ourselves and keep the trust levels high with you, the developers. Cheers, Dion Google Developer Programs Ajaxian.com

Re:solution in search of a problem

[Tumbarumba]

The file is indeed Javascript and it's called "urchin.js" (nice name eh?). "urchin.js" is the old name for the script. Google encourages webmasters to upgrade to the new ga.js, which has pretty much the same functionality, but some other enhancements. Both those scripts feed data into the same reports. If you're interested, you can see what the scripts is doing by looking at http://www.google-analytics.com/ga.js. It's pretty compact JavaScript, and I haven't gone through it to work out what it's doing. Personally, I use it on the website for my wife's children's shoe shop. From my point of view, the reports I get out of Google Analytics are excellent, and really help me optimise the website for keywords and navigation. I will admit though, that it is a little creepy about Google capturing the surfing habits of people in that way.

Re:dependence on Google is but one problem

[mckinnsb]

Being a Javascript programmer myself, I was wondering which post to reply to. I guess this one suits. There are a lot of issues I'd like to tackle, here.

Yeah, but what if Google decides that nobody is using these -- or they can't legally host them for whatever reason -- or they just decide that they don't want to do this anymore?

Then you go back to including a script tag in your header of your HTML document. All of these frameworks are free. They will likely remain free even though some are sponsored (mooTools). The speed improvement exists, but is moderate-to-minimal, since a packed full-inclusion library of mooTools runs you about 32kb. That's 32kb the user wont need to download again and again, but its just 32kb.

Think broader. What happens when: * Google decides to wrap more than just the promised functionality into it? For example, maybe "display a button" turns into "display a button and report usage stats"?

Even if the code is compressed and obfuscated, this "wrapped functionality" would become *glaringly* obvious to any javascript programmer using Firebug. The news would most likely spread like wildfire. Especially on /. The only thing they could track without really being monitored are which IP addresses are requesting the mooTools.js (for example) file. They could measure its popularity, but not *necessarily* what sites they are visiting. Granted- I haven't looked at the API yet, but if its just a .js file hosted on a Google server, there isn't really too much they can monitor that they don't already. Analytics provides them with *tons* more information. To be honest, this just seems like a professional courtesy.

There is a key point here I hope was visible - JavaScript is totally Load on Delivery, Executed Client Side. They can't really sneak much past you , and any efforts to do so would still remain visible in some way (you would see NET traffic).

* Google gets hacked and malicious Javascript is included?

Interesting, but I haven't seen Google hacked yet - not saying it can't happen, but I've not seen it. There is more of a chance of someone intercepting the expected .js file and then passing a different one- however, keep in mind that if you are doing *anything* that requires any level of security what so ever in JS, well, you have other, deeper fundamental problems.

But, yes- you're right. This is a scary new dependency. For a company full of PhD geniuses supposedly Doing No Evil, nobody at Google seems to understand how dangerous they are to the health of the web. In fact, I'd suggest they do, and they don't care- because they seem hell-bent on making everything on the web touch/use/rely upon Google in some way. This is no exception. A lot of folks don't even realize how Google is slowly weaning open-source projects into relying on them, too (with Google Summer of Code.)

It is a dependency, but its not that scary. Open source projects have always been, for better or worse, more or less reliant on outside momentum to keep them going. Joomla has conferences (that you have to pay to see), MySQL is powered by Sun, Ubuntu has pay-for-support. The fact that Google is willing to pay for kids to work on open source projects of their choosing (and granted, Google's selection), is not necessarily a form of control above and beyond the influence of capital. If I had millions of dollars, I would probably donate to open source projects myself - and they may be ones of my choosing - but I probably couldn't consider myself controlling them as much as helping them grow.

This is really nothing more than a professional courtesy offered by Google. They are right - its dumb for everyone to download the same files over and over again.

Furthermore, someone made a post earlier talking about JS programmers needing to learn how to use "modularity". We

Re:Umm, no

[Just Some Guy]

Some of us are still stuck on, gasp, dial-up. And loading an external JavaScript file is STILL far slower than inlining it.

Your grasp of the web sucks. Here's what happens on the second page you load on that site:

1. Send request for the page.
2. Read the page, sees it needs a JavaScript file.
3. See that the JavaScript file was already cached locally.
4. You're finished loading the page, so let people interact with it.

I use maybe 20KB of JavaScript in parts of my site. Why tack an extra 20KB onto each and every pageload, meaning that each takes about another 4 seconds for someone on dialup? To satisfy the screwed-up sense of purity for some premature optimization fan who doesn't really understand the issues involved? No thanks. My site is optimized for real conditions.

Re:Umm, no

[Just Some Guy]

Step 3 is always "send a new request".

Nope. You're flat-out, demonstrably wrong. Try watching an Apache log sometime. You see a visitor load a page, all its JavaScript, and all of its images. Then you see them load another page, and this time they only fetch the new HTML. There are no other GETs or HEADs - just the HTML.

Inlining script isn't hard, either:

Of course not. The issue is whether it's a good idea (it's not), not whether it's easy (it is).