[jrajav]

The memory leak issues you're referring to are old and have been fixed. They may be an issue if you are writing code that must support legacy IE, and then only in specific cases. However, if that's not you, then there's no reason not to use named function expressions. There's no other way to completely avoid arguments.callee (which is going away) for recursive reference, and it also makes call stacks and debug messages clearer. You won't think either of those are a real issue until they are.

So no, I disagree that that's good advice to give to a new programmer.

[nadaviv]

The memory leaks issues are effecting IE <= 8, which still has around 10% market share. Losing one of ten potential customers is not acceptable for most businesses. Unless you're writing server-side JavaScript, or have a specific demographic that uses newer technologies, those kind of bugs are not something that you should ignore.

To address your other points - you can get a recursive reference by simply assigning your function to a variable, `var f = function(){ f(); }`. There's no need for named functions for that.

As for call stacks and debug messages - that was true some time ago, but modern debugging tools can figure out the function name pretty good even if it isn't a named function. I work with CoffeeScript code(who doesn't have named functions) and stack traces are fine.

I think its a better practice to avoid named function expressions on client-side code. Non-expression named functions are fine, but considering that named function doesn't actually have any benefit (I don't consider hoisting a benefit - I prefer to have my functions declared before they're used), I can see why some people would decide to just avoid them altogether.

edit: spelling

[jrajav]

> To address your other points - you can get a recursive reference by simply assigning your function to a variable, `var f = function(){ f(); }`. There's no need for named functions for that.

> (I don't consider hoisting a benefit - I prefer to have my functions declared before they're used)

> As for call stacks and debug messages - that was true some time ago, but modern debugging tools can figure out the function name pretty good even if it isn't a named function.

All of these ignore the fact that functions are not simply declared once in Javascript and then used later, like in C. It's a dynamic language with first-class functions and function literals. You could assign to a variable in this case, but that's needlessly restricting:

  asyncFunc(function cb(result) { print(result); });

As for IE and memory leaks, I already acquiesced to the need to support it in some cases. Still, for many people it is acceptable to drop support for IE8 despite its general market share, and this leak may not be an issue if the function in question is not related to repeating code. Certainly you should not ignore the issue.

[nadaviv]

  > All of these ignore the fact that functions are not simply declared once in Javascript and then used later, like in C. It's a dynamic language with first-class functions and function literals. You could assign to a variable in this case, but that's needlessly restricting:
  >
  >   asyncFunc(function cb(result) { print(result); });

The assignment itself is an expression too, that returns the assigned value - the function in that case. You can just do that:

  var cb;
  asyncFunc(cb = function(result) { print(result); })

I would agree that having to declare the variable separately is a bit annoying, but I'm mostly writing CoffeeScript which doesn't require you to explicitly declare variables, so it doesn't really bother me.

Other than hoisting and leaking memory, nameless function expressions can be used to anything that can be done with named functions.