views:

140

answers:

7

Are there any benefits to using the 'window' prefix when calling javascript variables or methods in the window object? For example, would calling 'window.alert' have an advantage over simply calling 'alert'? I can imagine using the prefix could give a small performance boost when the call is made from inside some function/object, however I rarely see this in people's code. Henceforth this question.

+3  A: 

I doubt there is any measurable performance benefit. After all the scope chain would be scanned for the identifier window first then the window object would be scanned for the desired item. Hence more likely it would be deterimental to performance.

Using window prefix is useful if you have another variable in scope that would hide the item you may want to retrieve from the window. The question is can you always know when this might be? The answer is no. So should you always prefix with window? What would you code look like if you did that. Ugly. Hence don't do it unless you know you need to.

AnthonyWJones
I had no idea the scope chain would be scanned for window! I always thought window was a reserved keyword, and it thus wouldn't happen. Thanks.
Protector one
A: 

I imagine that the performance benefit here is amazingly insignificant at best, if there is one at all.

Symphony
A: 

It only matters if you're using frames and doing a bunch of javascript calls across frames, and even then only specific scenarios warrant the necessity of referencing window explicitly.

Peter Bailey
A: 

When you use the prefix, you're making it explicit you're using the "global" definition of the variable, not a local one. (I'm not sure whether / how you can inject variables into a scope in JS, except the weirdness with this and inline event handlers.) YMMV, you may either prefer the clarity, or find it to be just clutter.

Sii
+3  A: 
Dining Philanderer
+1 informative =)
Jon Erickson
+1  A: 

This is useful when attempting to test global object values. For example, if GlobalObject is not defined then this throws an error:

if(GlobalObject) { // <- error on this line if not defined
    var obj = new GlobalObject();
}

but this does not throw an error:

if(window.GlobalObject) { // Yay! No error!
    var obj = new GlobalObject();
}

Similarly with:

if(globalValue == 'something') // <- error on this line if not defined
if(window.globalValue == 'something') // Hurrah!

and:

if(globalObj instanceof SomeObject) // <- error on this line if not defined
if(window.globalObj instanceof SomeObject) // Yippee! window.prop FTW!

I would not expect to see a significant performance difference, and the only other reason you might do this is to ensure that you are actually getting a value from the global scope (in case the value has been redefined in the current scope).

Prestaul
A: 

As far as performance, I think AnthonyWJones has it covered.

One use of the window prefix is to explicitly make something available outside the current scope. If you were writing code in a self-invoking function to avoid polluting the global scope, but there was something within that you did want to make globally available, you might do something like the following:

(function(){
    function foo(){
        //not globally available
    }
    function bar(){
        //not globally available        
    }
    window.baz = function(){
        //is globally available
        foo();
        bar();
    };
})();
Rojo