New kids on the block

It’s been a busy couple of months in the web application arena as Google launched the Chrome browser with its high-performance JavaScript engine (called V8 for lovers of oily bits). A faster JavaScript engine helps the performance of any Ajax web application, as does Chrome’s pseudo-multithreading.

I say “pseudo” because JavaScript itself isn’t multithreaded, nor is it likely to become so in the foreseeable future, but to get around this and make Chrome less vulnerable to crashes it runs each tabbed web page and plug-in in its own process. That way, if some page or plug-in ceases to respond, Chrome should neither crash nor hang. When you press Chrome launches its task manager, which shows all the processes running and lets you end any rogue ones if necessary. The same task manager is also located in the developer section, along with a rather useful JavaScript debugger and console that show you what’s happening “under the hood” of your client-side code.

My first impressions of Chrome were favourable – clean lines and fast rendering – so I did what I do with any new browser, set it as my default so every website I visit goes through it. That way, I soon get to see all its foibles and quickly learn whether I can live with it. Chrome’s rendering is supposed to be standards compliant and it uses the same engine as Safari, but I found a lot of forum posts rendered in such a small font as to be unreadable, plus my copy hangs whenever it opens a PDF, so I gave it up as default browser after a couple of months. It’s early days, and while it certainly shows promise it isn’t quite good enough yet, but it’s still in beta and has the potential to become a major player.

Internet Explorer 8 beta 2 has just escaped, too, and I have it installed on my laptop (alongside Safari, Opera, Firefox and Chrome, just in case). IE8 seems to be a very competent and, thankfully, much more standards-compliant browser than its predecessor. Because of its improved rendering of CSS sites, I believe that Microsoft may have a problem when IE8 is released, when new users browse certain websites that have crude or badly coded browser detection (often, it seems, the same ones that currently give rendering problems with Chrome). Such browser detection code is used to attempt to resolve rendering differences between browsers: we faced a similar situation before, when IE6 came along and its maverick interpretation of the CSS standards prompted many site designers to add code to detect Microsoft browsers later than IE5 and offer a different stylesheet.

Anyone who stops to think about this for more than a minute will realise that it’s a very bad idea indeed. Along came IE7 with a more conventional understanding of how CSS should be rendered, and whenever it was used to browse such a fudged site, the browser detection code misidentified it as the broken IE6 and offered an IE6-customised stylesheet that rendered incorrectly in IE7 (thus, ironically, causing users to think that IE7 was even less standards compliant than it is).

I’m sure that the same thing will happen with IE8 when websites mistakenly identify it as IE7 (or even worse as IE6) and serve up a stylesheet specially tweaked for the older version. Microsoft has provided IE8 with a compatibility mode in which it behaves like its naughty older brother, but I wonder how many users will install IE8, find that their favourite websites appear broken, loudly pronounce it a piece of *&@*! and give up on it, which would be a shame since IE8 does promise rendering that’s more faithful to the standards.