I am completely smitten with Google Chrome Frame. I don’t think it’s an overstatement to call it one of the more interesting developments in the web landscape to come about in some time, because it finally provides a real solution to the horror that is Internet Explorer. It’s not perfect, of course, but it’s an audacious start. If nothing else, it should give Microsoft a rather swift kick in the ass.

As I’m in love, and a huge nerd, the first thing I did was start stalking my new affection. The first step was to test the installation process – if you’re reading this page on IE, you’ve experienced the browser detection already. Google makes a script available that handles detection and redirects the user accordingly – it’s fairly straightforward and configurable enough to meet most needs. The installation is painless, no more complicated than installing Flash or a PDF reader.

Next, I surfed around a bit, forcing “Chrome Frame” on certain sites – the best way to do this is by typing “cf:” before the full web address[1], including the “http:” e.g. “cf:http://google.com/”. I tested several sites that I visit regularly, just based on “feel”, and the anecdotal speed increase I noticed was incredible. Heavy sites, with lots of javascript, CSS, images and calls to third party sites, like ad servers, loaded in an order of magnitude faster. I didn’t run any hard and fast numbers, but this was the first time I’d ever say IE “felt” fast. It wasn’t flawless, crashing IE on me once, with an error that “Whoa! Google Chrome has crashed! Restart?” but this is a pre-beta developer preview, so I suppose that’s to be expected.

Something that surprised me is that Chrome Frame continues to use IE’s underlying architecture for non-rendering features, like cookies, history and remembering passwords. As a developer, I’d say that this is a nice to have, but as a user, this is essential – replacing the rendering component of the browser should be seamless and it shouldn’t require me to re-log into Hotmail. I’m surprised, though, because this is the sort of thing that I’d expect to be Hard and missing from a pre-beta preview yet it Just Works.

Another nifty bag of tricks that Chrome Frame brings along with it are the Webkit developer tools, as seen in Chrome (the browser) and Safari. Right click on a page being rendered in Chrome Frame mode, select “Inspect Element” and the inspector opens up. If you love Firebug or the Webkit web inspector, you’re going to love this. Of course, the DOM that you’re inspecting is the Chrome Frame rendered DOM, not the IE rendered DOM, so this doesn’t give you Firebug for IE, but it does provide a handy tool for debugging your code as Chrome Frame sees it.

I also got curious about the User Agent strings that Chrome Frame embedded inside of IE might return. If you’ve spent any time with User Agent strings, you might expect a certain amount of schizophrenia, depending on where you look for them, either on the server side or the client side. I wrote a quick PHP script to echo out the User Agent as PHP sees it and to echo out the User Agent as javascript sees it. The server-side detection sees the browser as IE, with one tiny exception: it adds a string “chromeframe” to the User Agent that you could easily look for and act on. The client-side detection sees the browser as Google Chrome – the exact same User Agent as when you visit the page using the Chrome browser.

If you think about how Chrome Frame works – a meta tag in the head of the page tells the browser to use a different rendering engine if that rendering engine is installed – this makes sense. Of course the server-side detection sees it as IE because nothing is telling the browser to switch identities yet. But the client-side detection sees it as Chrome Frame because the page itself, including the javascript that performs the detection, is rendered by the Chrome engine. As a developer, this is exactly what I want – the ability to see the actual browser based on the headers sent to the server, to detect for Chrome Frame via the added keyword in the User Agent string if necessary, and for the client-side to behave as if it’s been rendered by a single engine, not some Frankenstein hybrid. Bravo Google for getting this right. (To be perfectly clear, I’m not advocating browser sniffing as a path for development. As Kurafire points out, sniffing causes vastly more problems than it solves).

Finally, I investigated just a little bit about how Chrome Frame is actually implemented. Google doesn’t seem to have made the source code available yet, but if you check out IE’s add-ons preference panel, you see that Chrome Frame is something called a “Browser Helper Object” or BHO. I’m not terribly familiar with the concept, so I spent a little time on the relevant Wikipedia page and Microsoft’s support sites.

It turns out there’s a sort of irony here – BHO’s were introduced in IE4 by Microsoft during the height of the browser wars with Netscape as a way of allowing developers to extend IE itself, so that the browser could become a development platform; sort of a precursor to Firefox’s Add-ons and XUL platform. Of course, with IE as your platform, you’d want to write your web pages so that they’d render in IE and use all of the proprietary IE extensions that Netscape didn’t implement, or so the conspiracy goes. It turns out that BHO’s were most popular as a way to add toolbars – like the ones from Alexa and Google’s own search toolbar – and as a vector for writing viruses. Microsoft tried to fix this in IE 6 SP2 by sandboxing BHO’s and including an Add-on Manager that would let users scope out and uninstall any BHO’s that had installed themselves with nefarious purposes. This is also why you need to have at least Windows XP SP2 to use Chrome Frame, to support Chrome’s own security sandbox.

The irony here, as I see it, is that an old, insecure feature Microsoft built to try to beat Netscape is now being used by Microsoft’s biggest current rival to patch IE. The upside for developers is that Microsoft is going to have a hard time killing Chrome Frame because it actually does the right thing – it’s not hacking IE via undocumented APIs or unscrupulous haxie-like code injection. They used Microsoft’s own well-documented and fully supported platform to do this. Bravo indeed, Google.

So, what’s a developer to do with all of this? Of course, we can’t scrap IE entirely just yet and your own development plans should be dictated by your site’s unique audience. However, I’d suggest that Chrome Frame potentially makes designing for progressive enhancement even more realistic. Imagine being able to design with all of the modern tools like HTML 5, CSS 3, SVG, and performant javascript and telling all of your users, even the ones using IE 6, that this can all be theirs if they’ll just install a quick plug-in. No need to migrate to a new browser, learn a new UI and port over all of your bookmarks if you’re so curmudgeonly that you haven’t abandoned IE by now – those features can come to you!

Maybe one day Microsoft will finally get with the program and embrace the future instead of dragging the weight of the past decade along with them. Until then, we devs have a new love.

[1] You can also hack the registry to force CF mode on particular sites but I’d be careful, thar be dragons.