As of a few years ago (not sure about now) the backtrace frame info for anonymous functions were far worse than ones defined via the function keyword with a name.

All the wise ones. Well, except for you maybe.

Serious arguments would be:

- readability - greppabiloty

(It wasn't an insult, but a joke on the username)

Anonymous functions don't have names. This makes it much harder to do things like profiling (just try to find that one specific arrow function in your performance profile flame graph) and tracing. Tools like Sentry that automatically log stack traces when errors occur become much less useful if every function is anonymous.

    const foo = () => {}

This function is not anonymous, it's called foo.

Does the function know it’s called foo for tracing/error logging/etc?

But to call foo in bar you must define foo before bar.

function foo(){} is also callable if bar is defined before foo.

Not true at the top-level.

Not sure what you find not true about it. All named “function”s get hoisted just like “var”s, I use post-definitions of utility functions all the time in file scopes, function scopes, after return statements, everywhere. You’re probably thinking about

  const foo = function (){}

without its own name before (). These behave like expressions and cannot be hoisted.

> I use post-definitions of utility functions all the time in file scopes, function scopes, after return statements, everywhere

I haven't figured out if people consider this a best practice, but I love doing it. To me the list of called functions is a high-level explanation of the code, and listing all the definitions first just buries the high-level logic "below the fold". Immediately diving into function contents outside of their broader context is confusing to me.

I don’t monitor “best” practices, so beware. But in languages like C and Pascal I also had a habit of simply declaring all interfaces at the top and then grouping implementations reasonably. It also created a nice “index” of what’s in the file.

Hoisting also enables cross-imports without helper unit extraction headaches. Many hate js/ts at the “kids hate == and null” level but in reality these languages have a very practical design that wins so many rounds irl.

Interesting, it seems that the javascript runtime is smart enough detect this pattern and actually create a named function (I tried Chrome and Node.js)

    const foo = () => {}
    console.log( foo.name );

actually outputs 'foo', and not the empty string that I was expecting.

   const test = () => ( () => {} );
   const foo = test();
   console.log( foo.name );

outputs the empty string.

Is this behavior required by the standard ?

Yes, in great detail. https://tc39.es/ecma262/multipage/ordinary-and-exotic-object... is the specification, and for the TL;DR https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... is pretty good.

You're probably remembering how it used to work. This is the example I remember from way back that we shouldn't use because (aside from being unnecessary and weird) this function wouldn't have a name in stack traces:

  var foo = function() {};

Except nowadays it too does have the name "foo".

Not really, its an anonymous function stored in a variable foo

To me, arrow functions behave more like I would expect functions to behave. They don’t include all the magic bindings that the function keyword imparts. Feels more “pure” to me. Anonymous functions can be either function () {} or () => {}