> arrow "keyword" a very sensitive choice

I think you meant 'sensible' there.

I actually find the cs arrows a lot more useful than the es6 short-hand function definition, because a lot of the time I want to do be able to do composition, and the es6 one always binds the scope to where it's defined.

I love named functions otherwise, which ease debugging and understandability. I actually don't care for implicit returns, not just because i prefer being explicit, but because it's the cause of some very weird bugs at times.

Thanks! Updated.

Didn't know that about the new ES6 functions. I'll check it out.

Yes, named functions do improve debugging... But I guess it's worth the trade. I have come across very confusing code thanks to named functions.

Can someone please explain to me in a bit more detail what the advantage of not having named functions is?

There's a difference between assigning an anonymous function to a variable and declaring a named function. It's the difference between:

    var funcName = function(){}
    function funcName(){}

The problem is that using named functions involves nuances that can be confusing. Generally it's considered idiomatic to just avoid named functions altogether. You can read about some of the nuances here: http://kangax.github.io/nfe/

> Generally it's considered idiomatic to just avoid named functions altogether.

This is not idiomatic. Many developers only use named functions.

The obvious reason is they make stack traces far more readable, though you can get around this by naming functions anyway:

  var myFunction = function myFunction() {}

The hoisting 'nuances' you decry are a boon. Hoisting means you never have to worry about the order functions are declared – especially useful in cases where your functions call each other. You also get another avenue to declutter your code by pushing any crufty utility functions to the bottom of the page.

Named function expressions will cause memory leaks in IE < 9. Shouldn't be a problem forever, but some devs now might be impacted.

Pushing utility functions to the bottom of the current file is another reason to use a modular js architecture.

I read your link and found it to be very educational, but I don't believe it supports avoiding named function declarations, but rather named function expressions, since those are the source of inconsistencies between browsers.

My takeaway is that it is wise to avoid using named expressions, but fine to stick with anonymous function assignments, or declared functions. To add a third example to your list:

    var funcName = function(){};
    function funcName(){}
    var funcName = function funcName(){}; // <-- Danger!

Nice material! Thanks for sharing.

See http://stackoverflow.com/questions/336859/var-functionname-f...

There is no advantage. In fact, it's more annoying when you're debugging, since you don't get the fn name in the trace.