Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Microsoft IE 9 released

2011, infoq

I wrote a piece on InfoQ about IE9 being released, and I wanted to add some more colour to the point here. It’s not that I can actually run IE9 (doesn’t run on OSX) and at $DAY_JOB we tend not to get things in the same year as they are released either.

The point about IE9 is that it represents a new dawn for the IE platform. For years, IE has been the poster child of bugginess, only seen when a new version of Windows evolves (and then tied to it thereafter). Browsers like Chrome, Firefox and Safari have been driving the advancement of the web to the point where it’s finally starting to get feasible to write applications in JavaScript that execute on the client side, whilst consuming data over RCP or REST from a server, and have it work across all systems.

The big change has been HTML5, now called (confusingly) HTML. This reboot, originally from the WhatWG, brings a number of new features to the client platform, including:

These might not seem like big advances on their own (nor are they the only ones) but the Canvas is going to change how graphical applications (like Google Analytics) present data to the user, possibly even obliterating the ahead-of-its-time Google Chart image generation service.

The History API also seems out of place; why would that make nay difference? Well, the key is what it allows you to do with the URL bar. Historically, browsers have permitted scripts to change the document’s URL; but if they change the contents, the page is reloaded in its entirety. If the URL remains the same except for changes to content after a hash (#) character, then the page is not reloaded. This is why “new twitter” and others use http://twitter.com/#!/alblue – the # allows the script to update any parts to the right of the URL without causing page refreshes.

The hashbang was an approach to have a middle-of-the-road solution for Google crawlers. Unfortunately, it didn’t work out well for gawker since they forgot to put the Google hacks to get the content to still be rendered. But either way, it was a problem because JavaScript pages couldn’t update the URL without causing a page refresh.

The History API solves that problem. This permits a client to change the URL of the site to any value (although the protocol/domain/port is unchanged). Not only that, this “fixes” the browser’s back button, so that state transitions in the client cause the page to have an event fired which permits the page to reload the state at the time.

Sorry, but your browser doesn’t support history, or has JavaScript turned off

If your browser supports the History API (IE9, FireFox 4, Safari 5) then you’ll see a text box you can put in a text field. If you change it and click on the button, you’ll see it changing the URL of the page, as well as filling in a ‘history value’. Stepping back/forwards through the history with the back/forward button (or arrows) you’ll see the URL change, as well as the title of the pages in the history.

At the moment apps like Gerrit use a hashbang approach for representing individual changesets, reviews and such. However, in the future, we’ll be using real URLs as provided by the History API.