Function expressions and arrow functions

So far a function has been a thing you declare. Here is the idea that unlocks the rest of JavaScript: a function is also a value, like the number 7 or the string "hello". You can put it in a variable, hand it to another function as an argument, or return it from a function — which is lesson six.

Once you accept that, a second way of making a function is obvious. Instead of declaring it, create one and assign it to a const, exactly as you would assign a number. The function has no name of its own in this form; the name is the const you stored it in, and you call it the same way as always.

A function expression looks almost like a declaration with the name removed: the keyword function, brackets for the parameters, then the body in braces — all on the right-hand side of an assignment. Because the whole thing is one assignment statement, it ends with a semicolon after the closing brace, which is the small visual difference to watch for.

Everything you know still applies. Parameters, defaults, return, guard clauses — none of that changes. What changes is when the name becomes usable, which is the subject of two sections down.

An arrow function is a shorter way of writing a function expression: the parameters in brackets, then an arrow made of an equals sign and a greater-than sign, then the body. This is the form you will see most often in modern JavaScript, so it is worth being fluent in it even before you need the space it saves.

Arrows have two body styles and the difference is the one thing beginners trip on. If the body is a single expression written directly after the arrow — no braces — that expression's value is returned automatically. This is called a concise body, and there is no return keyword anywhere.

If you write braces after the arrow, you are back to a normal function body with statements in it, and nothing is returned unless you write return yourself. Braces switch the automatic return off. That is the whole rule.

Take a working concise arrow, add braces around the body so you can add a line to it later, and you have just broken it. The expression is still there, still evaluated, and its value is now thrown away — the function returns undefined and nothing complains.

It is the same failure as lesson three's return-on-its-own-line: legal code that quietly means something else. When an arrow function returns undefined for no visible reason, look for braces that should not be there, or a missing return inside braces that should.

Lesson one showed that a function declaration can be called from above. A function stored in a const cannot, and the reason is worth understanding rather than memorising.

The engine knows about the const before the code runs — the name is reserved — but it deliberately refuses to let you use it until execution reaches the line that gives it a value. Between the top of the block and that line, touching the name throws a ReferenceError. That gap has a name in the specification: the temporal dead zone.

This is a feature, not an oversight. A function declaration can honestly be hoisted because its whole body is known in advance. A const's value is whatever the right-hand side works out to when that line runs, so there is nothing sensible to hand you beforehand, and JavaScript refuses to guess.

The practical consequence: with const-stored functions, definition order matters. Define before you use.

An arrow function is not merely shorter. It is missing several things a normal function has, and this course meets them at different points, so here they are named once so that nothing later comes as a surprise.

An arrow has no this of its own and no arguments object of its own — two keywords this course has not needed yet. It cannot be used with new to build objects. And it has no prototype property, which is the one you can observe right now with typeof, and which the exercise below uses to check that you really did write arrows.

For everything you are doing in this module, none of the missing pieces matter. Treat the two forms as interchangeable for now, prefer whichever reads better, and know that the differences exist so that when you meet this in a later module the behaviour is not mysterious.

Codebases vary, and neither answer is wrong. A common convention: declarations for the main named operations of a file, because they can be defined in whatever order reads best; arrows for short one-expression helpers, and especially for functions handed to other functions, which module five leans on heavily.

The thing that actually matters is not picking a side but being able to read all three forms without slowing down. When you open somebody else's project you do not get a vote on their style.

A function is a value and can be stored in a const. A function expression is the keyword function with no name on the right of an assignment; an arrow function is the shorter form. An arrow with no braces returns its single expression automatically; an arrow with braces returns nothing unless you write return. Const-stored functions cannot be called above the line that defines them, so definition order matters for them and not for declarations.