DomReady Event Methods in JavaScript Frameworks

ExtJs still remains Extjs, Sencha is the company name…
(«One of the benefits of the name change is also that it separates a product name – Ext JS – from the company name, Sencha», http://www.sencha.com/blog/2010/06/14/ext-js-jqtouch-raphael-sencha/ )

But everyone should still prefer Mootools :)

Im not a programmer, but it seems to me that the mootools makes the most sense. You are adding an event listener to the window to see when the DOM is ready.

Could just be that I like my event listeners.

I like the Mootools way the most(Prototype doesn’t look bad either, just a little more complicated). Almost all other frameworks have a separate method for adding domready, which I find weird, since isn’t really different at all compared to regular events. It’s not a big deal but for beginners it might be easier to remember the event name of domready than the whole method for just that one task.

I wonder what makes jQuery so popular? Is it the syntax? I’ve used Mootools for so long that everything else looks like clumsy when compared to it.

Wow, is everything in YUI so verbose and convoluted? I’ve not really explored it–this example is solidifying that for the conceivable future.

jQuery has an alternative/shorter ondomready:

$(function(){
//do stuff
});

I prefer the mootools approach myself. And I agree, the YUI code looks way too verbose, if the rest of the framework’s API translates to code like that then there’s reason in itself to avoid it.

Mootools code has a tendency of looking cleaner in general to me (prototype is similar but it has very wordy method names), which I think is largely due to the fact it takes the approach of prototyping and extending native objects.

@Jani Peltoniemi
I damn (totally^totally*+∞)>100% agree with you! Mootools syntax rocks so much that I don’t even dare to imagine myself using any other!

@Allen
YUI is the main reason I have delayed the creation of my first vBulletin4/Mootools style (template). Not only its syntax, pardon me, sucks, but it conflicts with other js frameworks. BTW, If I need to use a framework, I shall use only one. The one that is synonymous of FTW!!!

To add on, jQuery has several other variations to fire a DOM ready f’n:

1.
$(function(){
// $ code here
});

If $ has been released to the global namespace then this also works:

2.
jQuery(function($){
// you can now use $ here
});

The thing I don’t like about the Mootools approach is that it’s on Window. Seems like document would be a more meaningful place.

That being said, there’s also the native approach for browsers that support it (which is to say, pretty much everything but IE these days, and likely IE9):

​document.addEventListener(‘DOMContentLoaded’, function () {
// Etc
}, false);​​​​​

I love the libraries (particularly enamored with Dojo lately ;)) but it’s good to know how to do it raw too. :D

Oh, also meant to mention that dojo does have dojo.ready as an alias for addOnLoad as of 1.4. :)

@Brian Arnold:

Yeah
document.addEvent(‘ready’, function(){

})

or

dom.addEvent(‘ready’, function(){

})

would be the only think I would possibly change

I can understand that, though one could make the argument that .ready is better, if for no other reason than saving four bytes. :)

Also worth noting: addOnLoad (or ready, whichever) have more power inherently than the other libraries do — at least, that I’m aware of. For example, dojo.addOnLoad(obj, “someFunc”) will run obj.someFunc when the DOM is ready, or dojo.addOnLoad(obj, function () {/*…*/}) will run the anonymous function scoped to obj.

I know you could accomplish the latter by doing jQuery.ready(jQuery.proxy(function () {/*…*/}, obj), when using 1.4, and I’m sure other languages have similar (heck, native has bind in some newer browsers which would also do it). Still kind of a neat trick.

Oh, also, addOnLoad, thanks to the require mechanics of Dojo, actually lets you do some sorts of lazy loading. You could chain things, like

dojo.addOnLoad(function () {
// Bind to some button stashed in some node variable
dojo.connect(node, ‘onclick’, function (e) {
// Need something new!
dojo.require(‘some.other.thing’);
dojo.addOnLoad(function () {
// This only runs once the required module has loaded
}); // inner addOnLoad
}); // connect
}); // outer addOnLoad

Which is also to say that technically, addOnLoad isn’t listening just for DOM to be ready, but for all required modules to be loaded, no matter how nested.

A bit off-topic, I suppose, but it does show that things are a bit more powerful here. I suspect jQuery/RequireJS can do similar sorts of things, but I haven’t really dug into that yet.