Function Declaration vs Expression

Both create a function value. The difference is what the parser sees at the start of the statement. A declaration begins with the keyword function in statement position, so the engine creates the function and attaches it to the name before any code runs. An expression is the keyword function used as a value, assigned to a variable, stored in an object or passed as an argument, and it only comes into existence when that expression is evaluated.

That single difference produces several observable differences.

Hoisting. A declaration is hoisted with its body attached, so you can call it from a line above its definition. An expression behaves like any other value: its binding exists from the start of the scope, but the value only arrives when the assignment runs, and reading it earlier throws.

Naming. A declaration always has a name. An expression can be anonymous, and when you assign one to a variable the engine infers the name from the variable, which is why you see the name property filled in for you.

Position in a statement. A declaration is a statement and can stand alone. An expression is part of a larger expression, so it needs to be inside an assignment, a call argument, a return statement or similar.

This binding. Both are ordinary functions with their own this binding and their own arguments object. Neither is an arrow function; arrows are a separate syntax with different rules.

The common mistake is treating the two as interchangeable when they are not. A function expression stored in a constant is often the safer choice, because the behaviour is uniform: one rule for every function, no hoisting surprises and no accidental globals.

This is the practical difference you will be asked to demonstrate. A declaration can be called before its definition line because the engine lifts the whole function. An expression cannot, because the value is only produced when its line runs.

// A declaration is hoisted with its body, so this works.
console.log(declared());

// An expression is only assigned when its line runs.
try {
  console.log(expressed());
} catch (err) {
  console.log("expression:", err.name);   // "ReferenceError"
}

function declared() {
  return "declaration";
}

const expressed = function () {
  return "expression";
};

The error you get is a ReferenceError, because the binding for the constant exists in the scope but has no value yet. That is the temporal dead zone, and it is a different error from the one you get when a name was never declared at all, although both surface as a ReferenceError.

Two more observations from the same snippet. If the expression were assigned to a var instead of a const, the call would not throw. It would hand back the empty value and then fail with a different error when you tried to call it, which is a much less helpful message. And if the expression were a named function expression, the name inside the function would still point at the function, which is how a function can recurse without relying on an outer binding.

The takeaway for a team is that this difference is mostly a source of accidental behaviour. If every function in the codebase is a declaration, you get hoisting everywhere. If every function is a const-bound expression, you get none. Mixing the two in one file means every reader has to check which kind they are looking at.