Have you ever taken a look under the hood at the jQuery 1.4 source code and noticed how it\'s encapsulated in the following way:
(function(
Others have explained undefined
. undefined
is like a global variable that can be redefined to any value. This technique is to prevent all undefined checks from breaking if someone wrote say, undefined = 10
somewhere. An argument that is never passed is guaranteed to be real undefined
irrespective of the value of the variable undefined
.
The reason to pass window can be illustrated with the following example.
(function() {
console.log(window);
...
...
...
var window = 10;
})();
What does the console log? The value of window
object right? Wrong! 10? Wrong! It logs undefined
. Javascript interpreter (or JIT compiler) rewrites it this way -
(function() {
var window; //and every other var in this function
console.log(window);
...
...
...
window = 10;
})();
However, if you get the window
variable as an argument, there is no var and hence no surprises.
I don't know if jQuery is doing it, but if you are redefining window
local variable anywhere in your function for whatever reason, it is a good idea to borrow it from global scope.
Undefined
By declaring undefined
as an argument but never passing a value to it ensures that it is always undefined, as it is simply a variable in the global scope that can be overwritten. This makes a === undefined
a safe alternative to typeof a == 'undefined'
, which saves a few characters. It also makes the code more minifier-friendly, as undefined
can be shortened to u
for example, saving a few more characters.
Window
Passing window
as an argument keeps a copy in the local scope, which affects performance: http://jsperf.com/short-scope. All accesses to window
will now have to travel one level less up the scope chain. As with undefined
, a local copy again allows for more aggressive minification.
Sidenote:
Though this may not have been the intention of the jQuery developers, passing in window
allows the library to be more easily integrated in server-side Javascript environments, for example node.js - where there is no global window
object. In such a situation, only one line needs to be changed to replace the window
object with another one. In the case of jQuery, a mock window
object can be created and passed in for the purpose of HTML scraping (a library such as jsdom can do this).
window
is passed in like that just in case someone decides to redefine the window object in IE, I assume the same for undefined
, in case it's re-assigned in some way later.
The top window
in that script is just naming the argument "window", an argument that's more local that the global window
reference and it what the code inside this closure will use. The window
at the end is actually specifying what to pass for the first argument, in this case the current meaning of window
...the hope is you haven't screwed up window
before that happens.
This may be easier to think of by showing the most typical case used in jQuery, plugin .noConflict() handling, so for the majority of code you can still use $
, even if it means something other than jQuery
outside this scope:
(function($) {
//inside here, $ == jQuery, it was passed as the first argument
})(jQuery);
Tested with 1000000 iterations. This kind of localization had no effect in performance. Not even a single millisecond in 1000000 iterations. This is simply useless.
The undefined is a normal variable and can be changed simply with undefined = "new value";
. So jQuery creates a local "undefined" variable that is REALLY undefined.
The window variable is made local for performance reasons. Because when JavaScript looks up a variable, it first goes through the local variables until it finds the variable name. When it's not found, JavaScript goes through the next scope etc. until it filters through the global variables. So if the window variable is made local, JavaScript can look it up quicker. Further information: Speed Up Your JavaScript - Nicholas C. Zakas