I’m currently involved in developing a web application of moderate complexity using Ext to provide a ‘Web 2.0’ front end on a PHP/mySQL application.  We’ve endeavoured to make it work across a range of browsers – Firefox, IE, opera and Chrome.  And this is the blog article in which I vent my spleen about Chrome.

Because, you see, there are some occasions when Chrome is an absolute bag of spanners that behaves in a manner that just beggars belief, and it worries me immensely.  If IE behaved in the same way that Chrome does under certain conditions then the Chrome / Google Fanbois would be lighting their torches and waving their pitchforks as they headed out towards Castle Microsoft.

Giving Chrome it’s due, Chrome renders CSS well against standards, and is frequently faster than Firefox and IE in terms of delivering pages; where it does seem to be lacking is in it’s sensible handling of JavaScript. The general impression I’ve had over recent days with Chrome and JavaScript is that it’s incredibly picky about how it handles JavaScript that is less than perfectly formed – hence the ‘Maiden Aunt’ jibe.  It requires everything to be very right and proper.  I understand that any browser should be expected to deal with properly structured script, but in recent years I’ve found that the major browsers tend to behave in a pretty similar manner when processing JavaScript and tend to vary in behaviour when rendering CSS – hence the fact the some sites look different in IE than they do in Firefox or Chrome.

But I’ve encountered some horrendous differences in the way in which Chrome on one side and Firefox/IE on the other handle JavaScript.  Chrome seems to be very ‘tight’ in it’s handling of two aspects in particular; white space and commented out code.  I hope that following comments might prove useful to anyone doing JavaScript development – particularly with libraries such as Ext.  Note that these issues don’t occur all teh time with Chrome, but have occurred often enough to give me problems.

Watch the White Space

Chrome seems particularly sensitive to white space in places where you wouldn’t expect it to be.  For example:

• Avoid spaces following closing braces ( } )at the end of a js source file.
• Avoid spaces around ‘=’ signs in assignments. 
• Avoid blank lines within array definitions – don’t put any blank lines after an opening ‘[‘ before data.

Watch the comment lines

The // construct used to make a line in to a comment line needs to be handled with care with Chrome.  Don’t include it in any object or array definitions – whilst it works OK in IE, it can cause major problems in Chrome.

Indications of problems

If you’re lucky you may get a straight forward JavaScript error – in this case you will at least have an idea of what’s what.  If you’re unlucky you may end up with either an apparent ‘locking up’ of Chrome or a 500 Internal Error message from your Web server.  The ‘lock up’ will frequently clear after a few minutes – the browser seems to be waiting for a timeout to take place.  When the errors do take place, I’ve found that the loading of pages featuring JavaScript errors is terminated – it can give the impression that a back end PHP or ASP.NET script has failed rather than client side script.

In summary, just be aware that Chrome may not be as well behaved as one would expect.

And that’s my whine for the day over!