Live data from Hacker News

AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

ajaxian.com

11–20 of 20 posts

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#11
post #4

It's a neat idea, but I can't imagine using it. Do you really, really trust Google with your business? What happens when google decides to "fix" something in one of those frameworks that the upstream developers disagree with? Even worse, what happens when your app is irreconcilably broken because of something that happened at Google? Worse still, what happens when your app somehow becomes reliant on Google's version…

The scripts look like they're organized by versions, ie ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js, so google can't really do any 'fixes' if they want to stick to the original authors' versions. Being afraid of have to 'depend' on this isn't a big problem; it's just a text file. You can create a constant in your codes for the URL string so that you can change it easily. The Script.aculo.us and other libraries are pretty big, so having it load from Google would help a little.

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#12
post #8

Earlier quoted context omitted.

There's nothing new about depending on external parties - if your site hosts ads (or uses an external stats service) you're already running code hosted elsewhere, so you should probably be comfortable linking through to Google (I trust them a lot more than most ad networks). The question is always "do I trust this provider not to screw me over" - Google's developer network stuff HAS to be trustworthy or they'll lose…

As for your app becoming reliant on Google's version of the framework, you can always download the JS file they've been serving and host it yourself. You can't get locked in that way. This misses the point. I'm not concerned about where the file comes from. If breakage occurs with regard to where the download comes from, a few customers get annoyed while you fix it (or even better, you implemented caching and custome…

Aah I understand where you're coming from. I would be amazed if Google made changes to the libraries they are serving up (since it would undermine the entire concept of the hosting service).

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#13
post #12

Earlier quoted context omitted.

As for your app becoming reliant on Google's version of the framework, you can always download the JS file they've been serving and host it yourself. You can't get locked in that way. This misses the point. I'm not concerned about where the file comes from. If breakage occurs with regard to where the download comes from, a few customers get annoyed while you fix it (or even better, you implemented caching and custome…

Aah I understand where you're coming from. I would be amazed if Google made changes to the libraries they are serving up (since it would undermine the entire concept of the hosting service).

It would definitely seem to go against the motto, right? You need look no further than Microsoft (and other software vendors whose entire strategy is based on lock-in), and assess the probabilities for yourself.

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#14
post #11
post #4

It's a neat idea, but I can't imagine using it. Do you really, really trust Google with your business? What happens when google decides to "fix" something in one of those frameworks that the upstream developers disagree with? Even worse, what happens when your app is irreconcilably broken because of something that happened at Google? Worse still, what happens when your app somehow becomes reliant on Google's version…

The scripts look like they're organized by versions, ie ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js, so google can't really do any 'fixes' if they want to stick to the original authors' versions. Being afraid of have to 'depend' on this isn't a big problem; it's just a text file. You can create a constant in your codes for the URL string so that you can change it easily. The Script.aculo.us and other…

Ah, the versioning is good, but still....

Maybe one possible solution to my concerns would be to keep a table of sha1 sums of the version you want to depend on, and check them periodically (randomly select 1 of every 1000 visits to receive the checking code that reports back to your backend).

I just have an instinctive wariness of this kind of dependency, even if the cost of avoidance is a performance penalty.

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#15
I still think I'd prefer to host them myself. When I used YUI style sheets hosted on Yahoo's servers they always took longer to load than local files. Also, Google ads are always the slowest item in a page to load. Until these libraries are embedded in the browser I don't see much benefit.

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#16
post #9
post #7

edit Nevermind, nothing to see here edit In the video they say that they used many of Steve Souders' techniques to speed up the deliver of the files since most web servers aren't properly optimized out of the box Looks like Google missed the part in Souders' High Performance Web Site where he talked about using ETag to speed up sites. :P curl -I http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js HTTP/1.1…

I don't think you need an ETag if you're serving a Last-Modified.

Oops, you are right. For some reason I thought using the If-None-Match header was the "right" way of doing this, it just adds flexibility to how you cache stuff.

http://developer.yahoo.com/performance/rules.html#etags

"If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether. The Last-Modified header validates based on the component's timestamp. And removing the ETag reduces the size of the HTTP headers in both the response and subsequent requests."

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#17
Related to this, people might want to take a look at Doug Crockford's suggestion:

http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB...

Basically, he suggests that every script tag have an option attribute called 'hash'. Whenever the browser downloads a script, it computes the hash and caches the script. For any further requests that specify that hash, the browser can used the cached copy instead of downloading a new one. The main benefit here is that everyone can continue hosting their own scripts, yet still take advantage of caching.

Brendan Eich (creator of JS) proposes a different solution:

http://weblogs.mozillazine.org/roadmap/archives/2008/04/popu...

In your script tags, you would specify both a local version (using the src attribute) and a canonical version (using a 'shared' attribute).

Brendan's concern about the hash solution is the poisoned message attack (http://th.informatik.uni-mannheim.de/People/lucks/HashCollis...). However, I'm not sure that applies here. I believe that you need to be able to generate both documents in order to easily find a collision. Anyone else know if that's true?

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#18
post #6
post #5

Earlier quoted context omitted.

While I think you have some good points, the difference between 20504 and 21919 bytes is completely meaningless.

It's brings it down to one request _and_ it reduces the filesize. Requests are relatively slow, you want as few as reasonable possible.

I tend to agree, and I didn't make any claims about the number of requests. But data transfer really isn't all that slow, and 1415 bytes only takes about 10 milliseconds on a dsl connection (and 100ms on dial up), which is insignificant compared to the other factors involved.

Re: AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

#19
post #18
post #6

Earlier quoted context omitted.

It's brings it down to one request _and_ it reduces the filesize. Requests are relatively slow, you want as few as reasonable possible.

I tend to agree, and I didn't make any claims about the number of requests. But data transfer really isn't all that slow, and 1415 bytes only takes about 10 milliseconds on a dsl connection (and 100ms on dial up), which is insignificant compared to the other factors involved.

and you assume all who are accessing your web application from n number of places over the world have such fast internet access. I doubt
Post reply on HN