There’s never been a better time to be a JavaScript developer. JS hit the big time with the advent of Ajax, and overnight client-side programmers went from being the redheaded step-children of the web-development world to front-and-center participants in the RIA revolution. Even if you’re working on a team of one, there’s a thriving global community of JavaScript gurus constanly pushing the language forward, working out browser kinks, demonstrating how to import concepts from other languages and computing paradigms, and otherwise inspire you. It’s a big change from 10 years ago, when you had Webmonkey and the David Flanagan book and a few cookbook-style compendiums of tips and tricks. This is seriously the golden age.
Working for the last couple of months on Really Simple History, though, I’ve become interested in the way specific techniques become the flavor of the month and quickly redefine how we conceptualize "good" JavaScript coding practices. Take, for instance, DOMContentLoaded. After the first version came onto the scene, within a matter of months we had many competing implementations of the basic concept that your scripts shouldn’t have to wait for window.onload to fire before getting down to business. Now, DOMContentLoaded is the de facto start point for many, many JavaScript applications. Heck, it’s even the basis of the entire jQuery event model. There’s nothing wrong with that, but widespread use of Ajax toolkits can conceal the fact that DOMContentLoaded is just a collection of hacks. It works, as long as our toolkits keep iterating one step ahead of the browser vendors. But do we really need it?
At Orbitz Worldwide, my previous employer, we implemented a first-rate unobtrusive-JavaScript architecture. (See it in action at Ebookers UK.) Everything was progressively enhanced from dumb markup. That meant our application worked just about everywhere. But it also meant lots of DOM parsing and initialization that couldn’t begin until window.onload. As our application grew, this caused enough of a UI flicker – form controls turning into widgets, links morphing into Ajax calls – that we needed to jump the gun on window.onload if we wanted a good experience for the majority of users … the ones with modern, JS-capable browsers. DOMContentLoaded made sense, and architect Nik Krimm pounced on it.
But for a large subset of websites, there really isn’t THAT much difference between window.onload and DOMContentLoaded. If you’re merely adding an unobtrusive behavior layer to a traditional, content-driven website, chances are that good old window.onload will perform just fine. There’s usually little reason NOT to use DOMContentLoaded. But unless you are developing a desktop-style webapp or implementing progressive enhancement on a foundational level, it’s not really necessary. And in certain cases, it just flat-out won’t work.
An enthusiastic beta-tester discovered such a case when trying to initialize RSH’s dhtmlHistory object from DOMContentLoaded. It broke, and I immediately knew why: RSH relies on the ability of modern browsers to auto-save form data for the life of a session. RSH uses a hidden textarea to cache serialized Ajax application state and render the back button useful again. Internet Explorer doesn’t repopulate the cached value of that textarea until an instant after window.onload. If you try to access that cache during DOMContentLoaded, it simply isn’t there. This is true of both IE6 and IE7. Therefore, you need to wait for window.onload.
I’m not really sure there’s any big conclusion to draw from this example. As I said, it’s just interesting to me that in the space of a year or two, DOMContentLoaded has become a de facto standard. As we pile browser hacks on top of one another to push the web forward, sometimes they’re going to conflict. Luckily, we can always peek past the curtains and figure out what’s going on behind the scenes.
I have found that by moving my JavaScript files to end of my body tag, I no longer need to worry about DOMContentLoaded. Since the browser has already parsed the page, all the proper DOM references have been made available to JavaScript. Also, the page appears to load faster for users, because the rendering doesn’t have to wait on the downloading/processing of JavaScript files.