Finally a chance to reflect on the Ajax Libraries API / Google CDN JavaScript library hosting
I was really excited to launch the AJAX Libraries API (I know, I know, I hate typing “AJAX” too…. haven’t you seen the rotating header on Ajaxian? ;) at Google I/O this week.
The only problem with the timing was that at the same time that it was getting picked up by the trade rags, Wired, reddit, Slashdot, Ars Technica, etc…. I was busy getting prepared and working Google I/O! This made it hard to stay up on what was being said and really being there to comment etc.
All in all I was shocked at the level of response. I knew that developers would get it, but seeing tech journalists see value in something that isn’t flashy or even provide something “new” surprised me.
There have also been some really good comments, and tips such as this one showing a nice way to use the API side of the house (google.load vs. script src) and load your other libraries after.
I also like the Wordpress plugin that seamlessly mixes local development and “production”.
Steve Souders also had some good thoughts and stats.
The key though is what happens next. To get something out of the door for a version 1 release, you sometimes cut features and just get it out. We have some great libraries out there now, but I want to aggressively get more out. We are not trying to be king makers here. Ideally I would love a system where anyone can add their scripts, but this isn’t as easy as you would think. For one, how do you stop people from putting bad stuff on there (if you could upload anything, you could put god knows what there). One of the core goals is to have stable releases on the system only. We have to make sure that we have the rights to do this, which means that the libraries are open source in a way that we feel safe.
That being said, we want to do a better job at getting feedback on the libraries that you want to see up there, so I am hoping to do something about that soon.
Lastly, there is room to do so much more. Steve Souders can help us with the performance side of things and has great ideas on how a loader could really add a lot of value here (e.g. choose how to add a script to the page depending on the use case). Then we can work with the browser vendors and see if there is a way to aggressively cache these libraries even more. Gears itself could also have a cache module that could do this. We need to think hard about how a hashing algorithm could work here, and make sure that it couldn’t be hijacked. Brendan has me scared there.
So, overall I am excited to see how we can build on this first release, and help the community further. Please let me know what you would like to see.
Check out more coverage in the news and across blogs.
June 2nd, 2008 at 10:03 am
Looking at my own project, I see that it’s not just jQuery that I want you guys to host, but all the myriad jQuery plugins and addons. Is that coming as well?
June 2nd, 2008 at 10:13 am
I am very excited about this too, especially if there was a way for the browser manufacturers to integrate it. MS isn’t going to use a Google CDN, though, so I’m hopeful some standard might emerge to keep the repo location flexible, while keeping it a simple one-liner for the JS developer.
June 2nd, 2008 at 12:04 pm
Well I got it because primarily I’m a web developer and secondarily a tech journalist :D When Ars needs someone to speak to something this technical, I cover that for them. Hopefully I’ll be able to cover this sort of stuff more and more often in the coming months :)
Great work on the project, btw. I hope to make great use of all this stuff in upcoming projects!
June 4th, 2008 at 7:10 am
I think the Google Ajax Library APIs are great for Ajax developers, but I had to LOL when I heard you say you were hoping to get browser vendors to ship them. There is no way that Microsoft, which still owns most of the browser market today, is going to cooperate with Google to ship the Ajax Library APIs with their IE browser. None.
Anyway, providing a single cached repository for the hundreds of Ajax APIs is a good thing, but it really doesn’t solve the problem that there are simply too many Ajax libraries (240 – 300 by my count) to maintain a stable ecosystem. Hopefully the number of libraries will diminish over time.
Richard Monson-Haefel
VP of Developer Relations
Curl, Inc.
June 5th, 2008 at 5:40 am
Hum, the Safari activity window shows that when loading our pages Safari is contacting google for each javascript file on every single page load. This is not ideal.
$ curl -i http://ajax.googleapis.com/ajax/libs/prototype/1/prototype.js
Last-Modified: Sat, 24 May 2008 00:39:29 GMT
Content-Type: application/x-javascript
Expires: Thu, 05 Jun 2008 13:17:24 GMT
Date: Thu, 05 Jun 2008 12:17:24 GMT
Cache-Control: public, max-age=3600, must-revalidate, proxy-revalidate
Transfer-Encoding: chunked
Server: GFE/1.3
Could this be due must-revalidate in the Cache-Control header?
June 5th, 2008 at 6:23 am
To answer my own comment, the short forms of the urls (without a fully specified version number) should be avoided for this reason. Using http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js works correctly, and there is no additional query to google after it is loaded the first time.
August 13th, 2008 at 6:34 am
This is tool is really very helpful. Ajax is my favorite language!
September 25th, 2008 at 3:37 am
Projects in AJAX, such as jQuery is a very useful and better from the same script in PHP.
October 29th, 2008 at 11:12 am
I like this blog so much!