Shared publicly  - 
super stupid javascript question number 2037892:
is there any real functional difference between declaring a function like:
function myAwesomeFunction(awesomeSauce) {
return awesomeSauce.doubleRainbows;
myAwesomeFunction = function(awesomeSauce) {
return awesomeSauce.doubleRainbows;
I see often these different styles in the same application and I wonder if it is just inconsequence or if it is for a reason...
Sir Peter Billing's profile photoFlorian Rohrweck's profile photoMalte Ubl's profile photoJoby Elliott's profile photo
don't know java all that well, but if its origins are as I understand them, then these two should work the same. If there is any difference it may be in the prior definition, or lack there of. Maybe some coders have defined MyAwesomeFunction as a function first, then assigned awesomeSauce to it. But the function myAwesomeFunction method may assign the datatype concurrently.

That's just a guess, though, based on 20 year old C+ training :)
+Dirk Heger 1000 points :D I guess that was what I was looking for.. gotta dive deeper once I start rewriting my code :D
I'm stupid about JS then, because it seems reasonable to ask the question. I don't detect any difference that in my opinion should be anything but syntactical sugar. I can guess that there might be a difference based on context, but can't see it within those snippets.
Ah, that does look like a difference. Not knowing JS, my next question would be "is it then allowed for other code to point this same function name to another function?"
You should probably do
var myAwesomeFunction = function(awesomeSauce) {
return awesomeSauce.doubleRainbows;
(See the var) unless you declared the variable earlier.
There are very little actual differences, except when you are in a block. E.g.
if (false) {
var fn = function() {};
is different from
if (false) {
function fn() {}
The latter always creates the function (except in firefox) while the first one never creates the function.
+Carlos Granier-Phelps got down what's happening, but there are side affects.

function fn () {} makes that function as a function, which means it's global.

var fn = function() {}; makes a variable containing an anonymous function. Since it's a variable containing a function it's bound by the scope of wherever you define it (like a normal variable). So if you define it inside another function it's not available outside that top function. This can be handy, but is also an easy way to find yourself confused and having erratic cross-browser problems.

Creating a function directly inside a function (function fn(){function fn2(){}}) is ill-advised (as evidenced by +Malte Ubl's observation of inconsistent browser behavior). Your best bet to do that is probably to assign an anonymous function to a variable, but omit the "var" so that the new variable is global (fn = function (){}).

Fun fact: variables declared anywhere without a "var" are made global. Isn't Javascript fun?
+Joby Elliott Not correct.
function foo() {}
creates a local name foo bound to the function just like
var foo = function() {};
The more interesting question is: What does
var foo = function bar() {}
do? :)

Your advice against local function is wrong and very dangerous:
1. Local functions give you encapsulation which limit overall complexity
2. There are no cross-browser problems with this. The difference of function statements inside blocks (such as the if I mentioned above) is one of the only browser differences in JavaScript. Everything else is extremely standard with zero kinks. Once you enter the realm of the DOM things look different, but JS itself is fine.
I stand corrected. Apparently I'm not up to speed on function statements inside blocks.

Although I'm not knocking local functions in the slightest, only creating them by function statements instead of anonymous functions on variables. Doing it with function blocks has given me trouble acting differently in different browsers.

I'm not sure what var foo = function bar(){} is doing.

I've poked around in it some, and found that it results in foo() calling bar() (which is not available globally, and the only place I can find it to exist is inside foo.valueOf), but I'm at a loss to explain how exactly this is happening.
Everybody buy this book
Only because something may sometimes not work as expected in the first place, does not mean there are inconsistencies. We humans are bad at empiricism and often imply patterns where there are none.
When you create a function in the format
MyFunction(params) { }
It is called a Function Statement

When you create it via
var MyFunction = function(params) { }
It is called a Function Expression.

One of the main differences is that the function statement gets a custom constructor which means you can use the "new" keyword with it to create a new instance of the function with its own context. You can't do that with the anonymous function since its constructor is the Function object itself.

If I remember correctly, there may also be a difference in how the delete command to remove properties on a function statement (I think it might not work) vs a function expression (I think it should work), but I need to verify that.

Using function expressions vs function statements otherwise is a matter of syntax preference. 
+Lindsay Donaghe Nope, both results of function expressions and function statements can be used as constructors. Even esoteric expressions like
new (function() {})
are perfectly valid.
There are also no differences with respect to delete; having said that, one should almost never use delete, except when emulating hash tables using JS objects.
Ok, I just tried it and yes, the constructors work in both circumstances after all. I wasn't expecting the evaluation of the function expression variable name to actually come back true when compared to an instance's constructor, but it did:

var MyFunc = function() { /*some stuff */};
var myFunc = new MyFunc();
var isSame = myFunc.constructor == MyFunc; // isSame == true

So that's interesting.

The only other difference I can think of then is that variables and function declarations are evaluated at different times, so maybe using one over the other can offer a timing advantage there for availability. But that would be such a special case that I can't think of a reason why you'd need to depend on it. The first answer here is is an interesting read demonstrating that timing difference:
if I declare them as variables and use them as callbacks all the way down several layers... could there be scope problems with local variables used by these functions?
Turtles all the way down -.- This stuff fucks with my brain...

well.. no, shouldn't be like that... uff I don't know

I'm confused.. but it works at least for now
+Florian Rohrweck Just know this: For all intents and purposes they are the same (if you do not forget the var). Especially scoping is exactly the same.
Add a comment...