Slashdot Mirror
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?"
Compared to all the other crappy media that sites tend to have these days, centralizing distribution of a bunch of Javascript libraries makes almost no sense. I doubt it would even appreciably reduce your bandwidth costs.
If you want to improve the speed of downloading, how about removing 70% of the code which just encodes/decodes from XML and start using simple and efficient delimiters? I was a fan of Xajax, but I had to re-write it from scratch... XML is too verbose when you control both endpoints.
It is not a problem to host an additional file, and this only gives Google more information than they need... absolutely no good reason for this.
This is only a partial solution. The real solution is for sites using AJAX to get away from this habit of requiring hundreds of kilobytes of scrip just to visit the home page. Couldn't you design a modular AJAX system that would bring in functions as they are needed? That way, someone visiting just a couple pages wouldn't have to download the entire library. Have each function in it's own file, and then when an AJAX call is done, make it smart enough to figure out which functions need to be downloaded to run the resulting Javascript. The problem with Google hosting everything, is that everybody has to use the versions that Google has posted, and that you can't do any custom modifications to the components. I think that what Google is doing would help. But the solution is far from optimal.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Now if only this could be done with GWT. Rather than building on a base-library, GWT vomits a slew of files all with hashed names. Since no two compiles are the same, you end up with an ever growing set of JS and HTML files sitting in the component directory. This is particularly annoying as all these files interact poorly with version control systems. (Even one as advanced as, say, Mercurial.)
At the very least, a standard ANT plugin so that GWT could be built at build-time rather than dev-time would do wonders for the project.
As a developer, privacy of my users is of paramount importance. I have grown increasingly concerned with Google's apparently incessant need to pry into my searches and my browsing habits. Where once I was a major Google supporter, I have trimmed my use of their service back from email and toolbars to simple searches and now even won't use their service at all if I am searching for anything that may be misconstrued at some point by guys in dark suits with plastic ID badges. The last thing I am going to do as a developer is force my users into a situation where they can feed the Google Logging Engine.
public void karmaWhore(String url){addSlashdotComment(fetchContent(url));}
Yes, you've gotta be careful with those incompetant sysadmins that Google are hiring.
After all, they're constantly getting the servers hacked.
If I were worried about bandwidth, why wouldn't I just use one of the packed down files? They're as small, if not smaller, than most of the images that will appear on a web page.
Additionally, if you're using compression, it is likely that one large file will compress more effectively than a collection of smaller files. (You *are* using compression, aren't you?)
Well, one effect of this would be to allow google to execute scripts in the security context of any site using their copy of the code. The same issue occurs for urchin.js etc. If your site needs to comply with regulations like PCI DSS or similar then you shouldn't be doing this as it means google has access to your cookies, can change your content etc. etc.
For many common sites that aren't processing sensitive information however, sharing this code is probably a very good idea. Even better would be if google provided a signed version of the code so that you could see if it has been changed.
Oh no! If Google decides they don't want to spend the $10/year this will cost them anymore, I might have to change a header and footer script! Or *gasp* use a search-and-replace to fix the URLs!
I'm *so* scared.
Google is supporting web apps and offering to host the nasty boring bits that need strong caching. How very evil of them.
And if Google is hacked, we're ALL screwed a hundred different ways. The average web developer *using* these libraries is more likely to have a vulnerable server than Google.
One site covering this noted plans to 'stay up to date with the most recent bug fixes' of the hosted libraries -- this sounds like blindly upgrading the hosted libraries to new versions, which is a very bad idea.
As a commenter there noted, it's a much better idea to use version-specific URIs, allowing users to choose the versions they wish to use -- otherwise version mismatches will occur between user apps and the Google-hosted libs, creating bugs and the classic 'dependency hell' that would be familiar to anyone who remembers the days of 'DLL hell'.
Single-point-of-failure, DNS-cache-poisoning, host-file-redirects, etc. etc.
You are not thinking this through!
In fact, the cache headers specify that the JS libs don't expire for A YEAR, so Google will only see the first site you visit with X library Y version in an entire year.
Is this information really that valuable?
Mind you, this assumes you're hard-coding the google-hosted URLs to the JS libs, instead of using http://www.google.com/jsapi -- but that's a perfectly valid and supported approach.
If you use their tools to wildcard the library version, etc. etc. then they get a ping each time that JSAPI script is loaded (again, no huge amount of info for them, but still you can decide whether you want the extra functionality or not).
I'll take the benefits of Google supporting open source over "GSoC is evil" paranoia.
If Google suddenly decides to stop hosting these, or touches them in some fashion, it's going to get discovered and fixed in well under 24 hours. Google hosting a file like this means that there are going to be a *lot* of eyes on the file.
Google is, as it currently stands, far from "dangerous to the health of the web". Outside of using their webmail fairly heavily, I could avoid using google quite easily- as could any other web user. Many websites are more dependent on them due to Google being their source of income, but the fact that Google has effectively created a niche for small websites to live in can hardly be viewed as a negative.
The ringing of the division bell has begun... -PF
No one said they were hackerproof. However, how often do you hear about them getting hacked? They put a significant amount of energy into security.
OK, hypothetical situation it is. Google offlines the javascript. All of your customers websites break, some of them are medium to high profile webbusinesses. For the next two or three hours, they aren't receiving any orders. Their potential customers think "Oh well, this site is broken, I'll just buy it from the competitor whose website seems to work".
Three hours have passed, and your customers suddenly realize there's something wrong with their website. They all call you in a timespan of 30 minutes. It takes you half an hour to find the problem, it takes you a couple of hours to fix all the sites. The business day is over.
Some of your customers are happy you fixed their website, but most will angry at you because you trusted a third party website with their business and they've lost potential revenue from that. You've lost time, cost customers money and potentially have lost future business with those customers.
And yet you haven't even thought of SLAs and lawyers yet.
Evil? No, not really. They've gotten publicity, some statistics, and a whole lot of people who are now depending on them while they've got a nice disclaimer somewhere waving most responsability.
In fairness to AC, he may also be connecting to some ancient or broken server that doesn't support the "Cache-Control: max-age" or "Expires:" headers. If that's the case, or if he's running a noncompliant browser that improperly handles those, then it's possible that he's making a lot more requests than necessary.
Either way, it's still a problem between his browser and that server, and not a problem with HTTP in general.
Dewey, what part of this looks like authorities should be involved?