In the answers to this question, we read that function f() {}
defines the name locally, while [var] f = function() {}
defines it globally. That makes p
The simplest explanation:
function aaaaaaa(){
Can be used before it is declarated:
aaaaaaa();
function aaaaaaa(){
}
But this doesn't work:
aaaaaaa();
aaaaaaa=function(){
}
That's because in the third code, you are assigning aaaaaaa to an anonymous function, not declaring it as a function.
This two snippets declares a function in the current scope, named "onload". No binding is done.
function onload() { ... }
.
var onload = function() { ... }
This snippet assigns a function to a property/variable/field named "onload" on the current scope:
onload = function() { ... }
The reason why Firefox performed the binding and raised the onload event on the 1st snippet and the others didn't might be because the Firefox chrome (its user interface) itself is written and automated using JavaScript - that's why it's so flexible and easy to write extensions on it. Somehow, when you declared the locally-scoped onload
function that way, Firefox "replaced" the window
's (most likely the local context at the time) implementation of onload
(at that time, an empty function or undefined), when the other browsers correctly "sandboxed" the declaration into another scope (say, global
or something).
var onload = function() {
alert("hello");
}
Will declare it locally too.
I suggest you to read this very helpful article : http://kangax.github.io/nfe/
Many people are correctly pointing out the global / local difference between (UPDATE: Those answers have mostly been removed by their authors now)
var x = function() {
and
function x() {
But that doesn't actually answer your specific question as you aren't actually doing the first one of these.
The difference between the two in your example is:
// Adds a function to the onload event
onload = function() {
alert("hello");
}
Whereas
// Declares a new function called "onload"
function onload() {
alert("hello");
}
Here's what I think is going on, based on Tim Down's helpful comments and a brief discussion with Jonathan Penn:
When the JavaScript interpreter assigns to the window.onload
property, it's talking to an object that the browser has given it. The setter that it invokes notices that the property is called onload
, and so goes off to the rest of the browser and wires up the appropriate event. All of this is outside the scope of JavaScript — the script just sees that the property has been set.
When you write a declaration function onload() {}
, the setter doesn't get called in quite the same way. Since the declaration causes an assignment to happen at parse time, not evaluation time, the script interpreter goes ahead and creates the variable without telling the browser; or else the window object isn't ready to receive events. Whatever it is, the browser doesn't get a chance to see the assignment like it does when you write onload = function() {}
, which goes through the normal setter routine.
This generates an error:
foo();
var foo = function(){};
This doesn't:
foo();
function foo(){}
The second syntax is therefore nicer when you're using functions to modularize and organize your code, whereas the first syntax is nicer for the functions-as-data paradigm.