Google’s proposal is to define a convention for URLs that contain state information in the anchor and to define a convention for retrieving the canonical, indexable contents of the an URL with such an anchor tag. First let me dismiss the suggestion that you make a headless browser available over HTTP to render your AJAX pages to HTML out of hand. If it’s so easy for HtmlUnit to render your AJAX to HTML, surely Google can do it. And basically offering HtmlUnit as a web service on your server doesn’t sound that secure or scalable to me.

The bigger question is that if your solution requires the server to be able to serve the correct HTML for any state, would you come up with the same solution as Google? There is a simple, straight-forward solution that works today and is used on sites all over the internet. If the content you serve includes the static, non AJAX URLs in anchor HREFs but uses JS click handlers to do AJAX loads then crawlers can scrape all of your pages, users of modern browsers get the full shiny experience and users on old mobile browsers that don’t support JS get to work for free!

To do this you can either make your AJAX templates include onclick handlers or you can write a simple piece of JS to do the right thing when any link is clicked on. A contrived example using jQuery might look like:

      $(function(event) {
        $('body').click(function(event) {
          var href = $(event.target).attr('href');
          // don't try to AJAX absolute URLs
          if (href.match('https?://')) return;
          // don't let the normal browser navigation operate
          event.preventDefault()
          // based on event.target.href, decide what AJAX URL to load.
          $('#ajaxframe').load('/load-fragment', {path: href});
          // update the URL bar
          document.location.hash=href;
        });
      });

This will intercept clicks on relative anchor tags and let your page JS do its AJAX magic. It doesn’t require special conventions. If you build your site this way you’ll probably find that the state that is in your URL fragments is a the relative URL for the page on your site. So http://www.example.com/random/page and http://www.example.com/#/random/page have the same meaning. That turns out to be a pretty good convention. After all, aren’t our URLs supposed to refer to resources anyway?

I was particularly excited at the chance to play with ActionScript’s optional strict typing since that has been under consideration for future versions of JavaScript / ECMAScript. AS3’s strict typing hasn’t felt optional to me because I’ve been largely using the Flex Builder IDE and it excitedly warns me every time I fail to specify a type on a variable or function signature, so I put them everywhere. Instead of implementing encapsulation using conventions like I do in JS I use AS3’s Interfaces. This felt good at first but I quickly realized that I couldn’t do the kinds of tricks that I’d become accustomed to in JS. I can’t create a typed object in a function and return it without defining a class for it in its own file. This has made the higher level structure of my software far closer to Java than to JavaScript.

On the other hand, inside my functions I’m pretty much writing JavaScript. All of the standard JS built-in objects (Object, Array, Math, etc) behave like modern JS implementations. I use anonymous functions to manipulate and filter arrays. I use Objects and Arrays as my primary data structures.

At this point I’m pretty used to AS3. I know how to design my code and I can be pretty productive, not needing to rewrite everything too many times. I’d like to see Adobe mix the Java-style classes and interfaces up with the JavaScript habit of declaring anonymous functions and objects as you go. I’d be thrilled if I could write something like:

var x : IMyInterface = new IMyInterface {
method: function() : void { ... },
field: 42
};


I see that they’re extending the language to support limited generics support so hopefully that won’t be the end of it. I’m looking forward to experimenting more on the platform.

I played around with Google’s new AJAX Translation API before and I wondered how hard it would be to use that from a GreaseMonkey script. The answer: hard. I’m not sure what the exact problem was but every way I tried to include Google’s APIs into the pages I was manipulating, including creating my own iframe and using document.write failed. In the end I used a static proxy html file (hosted in one of my Amazon S3 buckets for cheap efficiency) with some sneaky cross-site communication (the request goes over in location.hash, the response comes back in window.name).

My script is now up on userscripts.org: twitlator.user.js

To use it simply go to a page listing a bunch of tweets, like the public timeline and find a tweet in a language you don’t under stand. For example:

Click the translate! link and several moments later you’ve got:

Yep. People aren’t posting anything interesting in Japanese either.

I’m pretty sure my script will only work on Firefox 3. I’m using getElementsByClassName which I think wasn’t introduced until Firefox 3. Why aren’t you running it already?

I remembered John Resig’s hack from a few months back, getting enough of the DOM in Rhino to run some of the jQuery unit tests. I pulled that down, wrote the bits of DOM that were missing and now I’ve got a Java and JavaScript environment for accessing Google’s AJAX APIs. Apart creating stubs for some methods that are called the main functionality I had to implement was turning Google’s APIs’ asynchronous script loading into the Rhino shell’s load(url) calls. They use <script src="... and document.createElement("script"), but both are pretty easy to catch. The upshot of this is that everything is synchronous. This subtly changes a lot of the interface. For example, my Language API example looks like this:

load('ajax-environment.js');
load('http://www.google.com/jsapi');
google.load('language', '1');
google.language.translate("Hello world", "en", "es",
  function(result) {
    print(result.translation);
  });

it of course prints: Hola mundo.

I’ve put the source up on github. Have a play, tell me what you think.

Web pages being displayed in Songbird can (with the user’s permission) interact with pretty much the whole music player. We’re exposing both basic playback controls (what’s the current track, play, pause, next, etc) and access to the music library (see what’s in the library, add to it, etc). This means any music web site can offer a really rich integrated experience. Sites like last.fm or Pandora could offer recommendations without requiring you to download a plugin or desktop application, music stores like Emusic or Amazon.com wouldn’t need to provide a separate desktop applications and could offer the kind of seamless player / web-service integration that only Apple is providing at the moment, and there are a million other possibilities that we haven’t even thought of yet. Right now you can see this at work on The Hype Machine.

Steve and I have been hacking on Greasemonkey, getting it integrated with the bird and writing userscripts that add new functionality to web sites that don’t yet know about Songbird. My most complete hack is one that adds album previews (courtesy of Amazon.com’s music store) to album reviews on Metacritic and Pitchfork. It’s useful and its fun!

PS: yes, it supports your bloody iPod…