Category Archives: specifications

DOMContentLoaded is finally here!


DOMContentLoaded. It’s an event like the (on)load event that fires once an HTML document has finished loading, but it is tons more useful than the good old load. You see the problem with the load event is that it fires after the complete page has finished loading, including any embedded resources such as images. This is usually not what we actually want in Javascript, because it will make our scripts wait for the last image to load before coming into action, making our page seem slower than it could be.

What we want instead is for our script to fire as soon as the HTML document itself has finished loading, but before all the images have actually loaded. We just want to make sure the DOM is complete so we can safely manipulate it.

Enter DOMContentLoaded.

Browser support

DOMContentLoaded was first introduced by Mozilla and slowly has gathered more following. It was implemented by Opera and Webkit (which also means Safari and Google Chrome), so it was supported by all browsers except of course Internet Explorer. So we had this very useful event but couldn’t rely on it because the browser with the largest market share did not support it. But that has finally changed! And we have HTML 5 to thank for it!


As part of the HTML 5 effort the W3C is standardizing the DOMContentLoaded event and other actions that the browser is supposed to perform when it reaches the end of the HTML document in section 8.2.6 of the HTML 5 specification. And because Internet Explorer 9 is betting heavily on supporting HTML 5, they have implemented DOMContentLoaded! You can test drive it here.

Supporting old browsers

So there you have it. DOMContentLoaded is now supported by all major browsers. It will of course still take some time before the old browsers have disappeared from the scene so we will still have to support fallback code for some time to come. For that reason Packages JS, my personal stab at a modular Javascript framework, comes with a version of the famous addEvent and removeEvent functions in the package dom.event that transparently support DOMCOntentLoaded on old and new browsers alike, always giving the best possible result for the browser the script is actually running on. But that’s for another post.


OSGI for Javascript

We recently started working with OSGI (1) in our project and it’s petty nice. It’s a system for managing dependencies at runtime, enabling deploying and undeploying modules at runtime, with modules (‘bundles’ in OSGI terminology) automatically being stopped when a module it depends on goes away for some reason, and restarted when it comes back. Not too big or complex, just a small framework that gets the job done. Actually OSGI is a specification and the framework is an open source implementation of it called Apache Felix (2).

We develop in Eclipse and recently I stumbled upon an article about Eclipse E4, the soon to be fourth incarnation of the Eclipse IDE.

What was interesting about it is that the Eclipse people are looking at projects like Firefox with very succesfull add-on systems and are aspiring to implement the same ability to be able to write plugins in Javascript. Traditionally Eclipse plugins are written in Java and deployed as OSGI bundles, but OSGI is not available for javascript. Javascript doesn’t even have packages and namespaces, let alone bundles. But the cool thing about javascript is that you can bend it to your will. So they implemented javascript namespaces in the same way the people of Dojo (3) did and on top of that created a system that will let you write OSGI bundles in javascript. How cool is that? This kind of clear dependency management is what’s needed to scale javascript powered web applications to the extent that they can rival desktop applications.