Google Chrome Frame: Why they did it and why it probably won’t work

On September 23, Google released Chrome Frame, an add-on for Internet Explorer (IE) 6-8. Chrome Frame allows websites to request that IE visitors use the rendering engine behind Google’s speedy Chrome web browser instead of IE’s native engine. A TechCrunch synopsis and the Chrome Frame page provide further explanation. This article offers strategic insight into why Google is aggressively pushing their own browser technology, whether Chrome Frame will succeed, and how Chrome Frame should be seen by web development clients.

Chrome Frame

Ask any web developer what they think of Internet Explorer 6 and you’ll hear an earful. The 8 year old web browser still commands nearly 20% of the browser market and is woefully inadequate at supporting modern standards, incurring millions of dollars for legacy support every year. IE 7 and 8 were big improvements, but as we’ve opined on before, even IE8 fails to support forward looking techniques supported by the competition.

In the 6 month since IE8’s release, competitors Firefox, Chrome, Safari, and even Opera, have all seen major updates. All of them introduced performance upgrades, in particular to their JavaScript engines. JavaScript is increasingly the engine for dynamic content on websites, from animations to on the fly content loading without page reloads (via AJAX). Google’s browser, Chrome, positioned itself from day one as focused on performance, JavaScript performance in particular. At least in theoretical tests, it more than delivers on its promise.

Continue reading Google Chrome Frame: Why they did it and why it probably won’t work

3 simple examples: why Internet Explorer 8 disappoints web developers

UPDATE: Paul Thurrott, a Windows journalist, has featured some commentary on our post over at his Winsupersite. Check out his post, and the great discussion below it! Thanks for the input, Paul!

Internet Explorer 8 is out, and a lot of people – technically sophisticated and otherwise – are wondering what, if anything, this means for the web. As professional web developers, our view is that while Internet Explorer 8 is an incremental improvement over its predecessor, we’re mostly disappointed by its lack of progress.

Having read a variety of takes on IE8, we were inspired to write this article for two audiences. First, there’s little in the way of concrete examples and clear explanations for a large swatch of the business technology decision makers (that many of our clients represent) who are often savvy about technology, but look to organizations like us for a deeper understanding of the strategic, cost, and technical significance. Second, reading the comments on tech savvy websites like Neowin, Digg, and the Winsupersite have me concerned that there’s a growing and false notion that IE8 is just great, and its rendering problems are the result of web developers writing non-standard code optimized for IE7.

To understand why IE8 is a legitimate disappointment, we need to start by providing background on how different browsers impact web development, both from a cost and design standpoint. If you think you already have a handle on this, you can skip ahead to our 3 straightforward examples of IE8 disappointments.

Continue reading 3 simple examples: why Internet Explorer 8 disappoints web developers

iPhone / Android Optimized Theme

iPhone and Android optimized WordPress templateAfter our previous post onĀ mobile-optimized websites it seemed to us that we should lead by example. That’s why we’ve released version 1 of “C. Murray Consulting Mobile”.

For v1, we focused on the powerful and increasingly ubiqitous mobile WebKit, the website rendering engine used by the web browser on the iPhone and Google’s Android platform (available today on the T-Mobile G1) as well as some Nokia Symbian devices. It’s also the web engine behind the forthcoming Palm Pre. The core WebKit engine also powers Apple’s desktop Safari browser, and Google’s new Chrome browser.

As with any mobile project, there were two core principals that guided us. First, make it readable: minimize the amount of scrolling necessary and optimize the font for the small screen. Second, make it fast: minimize mobile load time by cutting unnecessary and weighty graphics and keeping the site light on client side scripting and complex styles.

If you have an iPhone or Android device, head on over to cmurrayconsulting.com and let us know what you think. We’ll be adding a check for other mobile WebKit devices, as well as a manual web address to check it out, soon.