This was originally a StackOverflow question. I’m re-posting here because I think the question is fairly common, and I like the answer that I provided.
Why define anonymous function and pass it jQuery as the argument?
This is the original question title, but it doesn’t really show the nuances of the question’s content. The StackOverflow user really wants to know the difference between an immediately-invoked function expression, and the jQuery DOMReady event:
At a high level, the two blocks of code shown are dramatically different in when and why they execute. They do not serve the same purpose. But they are not exclusive of each other. In fact, you can nest them in to each other if you want – although this can have some odd effects if you’re not careful.
jQuery’s “DOMReady” function
This is not a module, though. This is only a callback function passed in to the DOMReady alias. The major difference between a module and a callback, in this case, is that jQuery waits for the DOM to be ready and then calls the callback function at the appropriate time – all from the context of jQuery – while a module pattern or immediately invoking function executes immediately after it’s defined. In the above examples, the module is receiving jQuery as a parameter, but this is not the same as using jQuery’s DOMReady event because the module function is called, passing in jQuery as a parameter, immediately. It does not wait for the DOM to be ready. It executes as soon as the function has been parsed.
This is an immediately-invoking function expression (FKA “anonymous function”, “self-invoking function”, etc).
The implementation of this is a function that is immediately invoked by the calling (jQuery) parenthesis. The purpose of passing jQuery in to the parenthesis is to provide local scoping to the global variable. This helps reduce the amount of overhead of looking up the $ variable, and allows better compression / optimization for minifiers in some cases.
For more information on modules, see the following resources:
- WatchMeCode Episode 2: Variable Scope (covering modules, which provide scope)
- Ben Alman’s Immediately Invoking Function Expressions Post
Modules vs DOMReady In Backbone Apps
It’s bad form to define your Backbone code inside of jQuery’s DOMReady function, and potentially damaging to your application performance. This function does not get called until the DOM has loaded and is ready to be manipulated. That means you’re waiting until the browser has parsed the DOM at least once before you are defining your objects.
Modules And DOMReady In Backbone Apps
You’re likely going to use a DOMReady function even if you define your Backbone objects somewhere else. The reason is that many Backbone apps need to manipulate the DOM in some manner. To do this, you need to wait until the DOM is ready, therefore you need to use the DOMReady function to start your application after it has been defined.
Here’s a very basic example that uses both a Module and the DOMReady function in a Backbone application.
Note that we’re defining the module well before the jQuery DOMReady function is called. We’re also calling the API that our module defined and returned from the module definition, within the DOMReady callback. This is an important point to understand, too. We’re not defining our objects and our application flow inside of the DOMReady callback. We’re defining it elsewhere. We’re letting the application definition live on it’s own. Then after the application has been defined, and when the DOM is ready, the application is started.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.