The Journal Of E. A. Kolb

By now you should probably be aware that Google dropped a new browser on the market a couple weeks ago: Chrome. It's currently a beta product (version 0.2 and change) for Windows only, but it already seeing at least the active market share of Apple's Safari in the wild. Google Chrome is worth talking about not just for what features it does and doesn't bring to the browser market or its standards adherence. It's something worth talking about because it's not just Yet Another Web Browser from a code perspective.

I say this and mean it both as a good thing and as something that makes our jobs as web developers harder. And I say 'harder' in the sense that it will force us to not be lazy. Google Chrome changes how back-end browser processing works. For instance, each tab in the browser is its own system process, which optimizes memory recovery over a prolonged period of web use. More importantly, however, is that it changes how Javascript is processed.

For the last fifteen years (or however long Javascript’s been implemented on the browser level), Javascript has been a lock-step affair. Your document is read by the browser vertically. When a <script> block is encountered, its contents are executed, preventing the browser from taking any other action. That is not the case with Google Chrome. I’ve not got it entirely worked out yet, but it is definitely doing more things in parallel, including loading and processing of Javascript.

I'm not speaking for the rest of you, but one habit I've got with my web development is that I will pepper inline <script> tags throught my code. Usually, this is so relevant bits of Javascript remain in the same vascinity as the markup it drives. It might not be entirely proper, but it gets the job done and doesn't make a follow-up developer hunt for unmarried segments of ColdFusion/PHP and Javascript.

This fast-and-loose style of javascript programming has proven to be problematic in Chrome thus far. For instance, in the project I'm currently working on, I'm using Adobe's Spry as an effects and AJAX library in conjunction with ColdFusion's javascript libraries. The Spry includes create the global Spry object and I've had inline <script> blocks that would instantiate Spry effects or data sets. The issue that I was seeing in Chrome is that the inline blocks were sometimes being executed prior to the completion of the Spry includes, resulting in errors from invoking undefined properties of the global Spry.

Thus far, my solution to it has been to revisit the loose bits of inline javascript that I'm so used to peppering throughout our code. If you find yourself in a situation where Google Chrome is making your Javascript go busto, try this at a very early stage of processing.

Then, you can do this with your inline stuff:

This is going to give you control over all the little bits of JS you want to pepper into your document at will and will make sure it's all executed at onLoad (by which point all referenced Javascript files have been executed) in the order you want them executed. It also has the added bonus of meaning you never ever have to write an onload function that has to substitute some other onload.

Hope this helps.