Speed up access to your favorite frameworks via the AJAX Libraries API

May 27, 2008

Google engineers spend a lot of time working on speeding up their Web applications. Performance is a key factor for our teams, and we recognize how important it is for the entire Web.

When you take a look at the effort that it takes to setup work that should be simple, such as caching shared JavaScript libraries, you quickly realize that the Web could be faster than it currently is.

The AJAX Libraries API is an attempt to make Web applications faster for developers in simple ways:

  • Developers won't have to worry about getting caching setup correctly, as we will do that for you
  • If another application uses the same library (much more likely), they there is a much better chance that it will be already caching on the users machine
  • The network and bandwidth of the users systems will not be taxed.

What exactly is the AJAX Libraries API?

We have worked with a subset of the most popular JavaScript frameworks to host their work on the Google infrastructure. The AJAX Libraries API then becomes a content distribution network and loading architecture for these libraries.

We realize that there are a huge number of useful libraries out there, but we wanted to start small with the program, which has us starting with:

We work with the key stake holders for these libraries to make sure that the latest stable versions of their work get into our system as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>

The second way to access the scripts is via the Google AJAX API Loader's google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:


<script src="http://www.google.com/jsapi"></script>
<script>
// Load jQuery
google.load("jquery", "1");

// on page load complete, fire off a jQuery json-p query
// against Google web search
google.setOnLoadCallback(function() {
$.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",

// on search completion, process the results
function (data) {
if (data.responseDate.results &&
data.responseDate.results.length>0) {
renderResults(data.responseDate.results);
}
});
});
</script>


You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:

google.load("jquery", "1.2", {uncompressed:true});

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

We are really excited to offer something that we feel can truly help you out, and please give us feedback in our Google Group to let us know how the feature is working for you, and if you have a craving for a particular library to be included.

Non-Javascript LocalSearch

May 16, 2008

I wrote a non-Javascript version of Google Maps which is designed to show how easy it is to write an application on App Engine that makes use of two new APIs from Google: The Static Maps API and the Local Search API's REST interface. It doesn't have fancy stuff like street view and public transportation, but it gives you a searchable map that you can zoom in/out on as well as save locations. It also automatically saves your last map view so that every time you go back to the site it will show you what you were last looking at. Check out the source code.

It uses App Engine to store saved points, the AJAX LocalSearch REST API for search functionality, and the Static Maps API to display maps. I really enjoyed working with App Engine. It's free, easy to learn and the data store is very useful. Likewise, using the REST LocalSearch is beyond simple. Here's all you have to do in Python to retrieve search results:

query = urllib.urlencode({'q' : 'pizza near mountain view'})
url = 'http://ajax.googleapis.com/ajax/services/search/local?v=1.0&%s&rsz=large' \
% (query)
local_search_points = urlfetch.fetch(url)
json = simplejson.loads(local_search_points.content)
points = json['responseData']['results']
for i in points:
# output the information e.g. i['streetAddress']
To use the Static Map API, you just need to create a URL with the proper parameters for your desired map view. Keep in mind that you need to set the zoom level (unless you are specifying multiple points -- then it's calculated for you). In the vast majority of cases, this is completely fine. In my case, though, I needed to know what the zoom level was for multiple points and calculate it in cases where I only had one map point.

Here's the code to do this. From line 130 to about 296 you'll find the necessary functions to calculate a zoom level given a bounding box or a set of latitude/longitude points.

It's time to start cranking out those App Engine & AJAX APIs apps!

Google I/O developer conference: Now with more AJAX

May 5, 2008

With Google I/O just a few weeks away (May 28 - 29), if you haven't already registered then now is the time. There are now more than 80 technical sessions posted. In addition to the AJAX APIs sessions that we talked about before, we've recently added a number of other AJAX & JavaScript related talks:

State of AJAX: The Universe Is Expanding
Dion Almaer, and Ben Galbraith, founders of Ajaxian.com, will discuss the State of Ajax (hence the title), including the latest technology developments, techniques, and frameworks.

Even Faster Websites
Steve Souders, creator of Y!Slow and author of the book High Performance Web Sites, will explore the best practices that he's discovered for reducing latency and improving your app's performance.

Can We Get There from Here?
Alex Russell, co-creator of The Dojo Toolkit, looks at the state of the web development stack and the differing views and approaches to advancing development within a browser.

Be sure to visit the website to see the complete list and to register. For those coming from out of town, we've arranged discounted room rates at nearby hotels. Read the details on the website to take advantage of the discount, but move fast because the hotel discount ends May 6th.

See you in San Francisco.