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.
Every web developer on earth hates Internet Explorer for a very good, very valid reason: it sucks. Suck, in fact, doesn’t even begin to encapsulate the amount pain and angst IE causes web developers on a daily basis. The amount of time that I’ve personally spent writing code to route around the indomitable suck that is IE has quite possibly added up to years at this point. Years of my life dedicated to that slow, bloated, horrible piece of garbage. (I hope I’m not underselling this because I really, REALLY hate IE.)
Invariably, some rumor will pop up that the IE team is thinking about scrapping the awful, non-compliant, slow, buggy engine that they use to render web sites and replace it with something awesome, like Gecko or Webkit. These rumors are nothing more than teases because anyone who’s tracked Microsoft for any length of time knows that it’ll be a cold day in hell before that happens.
Fortunately, Google is full of smart people who aren’t willing to wait for Microsoft to get their act together and actually pay attention to the past decade of what’s been happening on the web. So they built Google Chrome Frame, a plug-in that actually replaces Internet Explorer’s rendering engine with the one that Google Chrome uses. Consider for a moment exactly how awesome that is. It literally installs a new HTML, CSS and javascript engine inside the otherwise abysmal browser, none the wiser to the user. One line of code, a plug-in install later, and all of the sudden, you no longer have to work around IE’s cruddy box model interpretation or dog-slow Javascript engine.
I’d like to think that this is the sort of thing that web developers will embrace en masse, but the reality is the uptick will likely be slow and for specialized applications that rely on lots of front end processing. But if it takes hold, it just might mean one of the few things that truly sucks about the internet goes away for good.