In the online REPL of Babel JS (/), when I type in :

let a = (x) => x+1

It will be transpiled to:

"use strict";

var a = function a(x) {
  return x + 1;
};

Here the var a = function a(x) looks a bit confusing to me, because either var a = function(x) or function a(x) is enough as I understand.

Does anyone have ideas about when and why it is necessary to assign a named function to a variable?

In the online REPL of Babel JS (http://babeljs.io/repl/), when I type in :

let a = (x) => x+1

It will be transpiled to:

"use strict";

var a = function a(x) {
  return x + 1;
};

Here the var a = function a(x) looks a bit confusing to me, because either var a = function(x) or function a(x) is enough as I understand.

Does anyone have ideas about when and why it is necessary to assign a named function to a variable?

• javascript
• ecmascript-6

Share Improve this question Follow asked Nov 10, 2015 at 9:47 Hanfei SunHanfei Sun 47.1k4141 gold badges134134 silver badges251251 bronze badges 10

• 2 It's not neccesary, but if the function doesn't have a name, it won't show up as 'function a' in stack traces in some browsers. So named functions can be beneficial for easing debugging. Else they'll show up like 'anonymous function'. – Shilly Commented Nov 10, 2015 at 9:49
• @Shilly there's another difference - a named function exposes its name to its own scope. – Alnitak Commented Nov 10, 2015 at 9:51
• @Alnitak: Wrong. It exposes its name to the scope (and with hoisting) only when it's a function definition and not a function expression. Here is a (named) function expression, and it will be accessible only through the variable (which has the same name in this case). But consider the case the var is called x, you would call the function a with x() because a() is undefined Basically the function definition on its own line function lol(){} would be identical to var lol = function lol(){} – Zorgatone Commented Nov 10, 2015 at 9:59
• @Zorgatone I think we're in violent agreement - I don't see anything you've written that disagrees with my assertion that a named function's name is available within the function's own scope. – Alnitak Commented Nov 10, 2015 at 10:02
• 2 I feel there is too much noise in the ments and the answers. So here is the tl;dr: 1) Arrow functions are expressions, not declarations, hence we need to use a function expression. 2) In ES6, the function name is sometimes inferred from the variable it is assigned to, hence a named function expression is used. Ideally one could just assign to a.name = 'a', but not all browsers support this yet. – Felix Kling Commented Nov 10, 2015 at 16:29

 |  Show 5 more ments

3 Answers 3

Sorted by: Reset to default 8

There are really two different questions here:

1. What are the differences between the different ways of defining or expressing functions?
2. Why does let a = (x) => x + 1 get transpiled this way?

In order to answer (2) we need to understand (1)-- which has been extensively discussed on SO and elsewhere.

---

Question 1

Let's go through the three alternatives you mentioned:

Function declaration:

function a(x) { ... }

Syntactically, these must always begin with function (reference). They are hoisted at parse time and create a named function in the local scope.

(Anonymous) Function expression:

var a = function (x) { ... }

var a itself will be hoisted at parse time, but it will be undefined until this line is executed at runtime.

Named Function expression:

var a = function a(x) { ... }

Though the syntax makes it looks like an assignment to a function declaration, this is actually just a function expression with a name. I find this confusing, but that's the syntax.

The big difference is between function declarations and function expressions. With a declaration, you can do:

a(1);
function a(x) { return x + 1; }

though attempting this with a function expression (named or anonymous) will cause an error.

---

Question 2

2. Why does let a = (x) => x + 1 get transpiled this way?

We're assigning the arrow function (x) => x + 1 to a block-scoped variable with let, so we should expect that a is not defined until after this line has been executed at runtime. This should be a function expression, not a function declaration.

Last, why is let a = (x) => x + 1 transpiled to a named function expression rather than a anonymous function expression? What's the difference? As Alnitak and others have pointed out:

• Function names appear in debuggers, which can be helpful.
• The scope inside of a named function definition has a reference to the function itself. This allows for recursion and accessing properties of the containing function.

So named function expressions have some nice properties that anonymous function expressions don't. But there actually seems to be disagreement on what should happen here. According to MDN:

Arrow functions are always anonymous

whereas this answer to Why use named function expressions? says:

"[As of ES6] a lot of "anonymous" function expressions create functions with names, and this was predated by various modern JavaScript engines being quite smart about inferring names from context... This is strewn throughout the spec"

Other references:

• var functionName = function() {} vs function functionName() {}
• Javascript - Precedence in hoisting

I've found that the best way to get a handle on this is playing around with the Babel REPL.

If you write:

function a(x) { }

then the function is hoisted to the top of the enclosing scope, and a bees available immediately at parse time within the entire scope.

However, when you write:

var a = function a(x) { }

then var a will not have a defined value in the enclosing scope until this line is actually executed.

However, within that function, a different a will exist as a locally scoped reference to the function itself.

By using the let a = function ... construct Babel is being more consistent with the latter form, ensuring that a is assigned at run time to a (named) function expression instead of using a parse time function declaration.

It appears that this is according to standard (12.14.4):

AssignmentExpression[In, Yield] : LeftHandSideExpression[?Yield] = AssignmentExpression[?In, ?Yield]

1.If LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral, then
  a. Let lref be the result of evaluating LeftHandSideExpression.
  b. ReturnIfAbrupt(lref).
  c. Let rref be the result of evaluating AssignmentExpression.
  d. Let rval be GetValue(rref).
  e. If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef of LeftHandSideExpression are both true, then
    I.   Let hasNameProperty be HasOwnProperty(rval, "name").
    II.  ReturnIfAbrupt(hasNameProperty).
    III. If hasNameProperty is false, perform SetFunctionName(rval, GetReferencedName(lref)).

So, whenever an assignment of an unnamed function expressions to a named identifier is evaluated, the function name should be set to the identifer name.

Babel follows this process, and generates a patible ES5 implementation.
Chrome (v46.0.2490.71, V8 engine...), doesn't follow this process, and name equals '' in that cases.

---

As for the question itself...

In Javascript, when is it necessary to assign a named function to a variable?

The answer is never. It's up to the developer to decide if / when to use a named function. The decision boils down to specific need for a name (such as when "stringifying" a function), or debug needs (better stack traces...).