Tail Call Optimization

The plain-language idea

A tail call is a function call that happens as the absolute last action in another function — nothing left to do with the result except return it. No multiplication after it, no concatenation, no wrapping it in another expression. Just return someCall(...) and nothing else.

Why anyone cares: when a call is in tail position, the current function's stack frame is no longer needed for anything. It's not going to do more work after the call returns — it's just going to hand the result straight back up. So an engine that recognizes this can, in theory, reuse the current stack frame instead of pushing a new one. A million tail calls deep would cost the same stack space as one call. This is called tail call optimization (TCO), and it's what lets some languages (Scheme, Elixir) write loops as recursion without ever blowing the stack.

See it in a real thing: factorial, done two ways

// NOT a tail call — multiplication happens *after* the recursive call returns
function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1); // work still pending: the multiply
}

// A tail call — the recursive call is the very last thing that happens
function factorialTCO(n, acc = 1) {
  if (n <= 1) return acc;
  return factorialTCO(n - 1, n * acc); // nothing happens after this returns
}

In factorial, the engine has to remember "multiply this by n" for every pending call — that's real stack growth, one frame per call, because each frame still has unfinished business waiting for its child to return. In factorialTCO, the multiplication happens before the call, folded into the accumulator argument, so the recursive call really is the last statement — there's nothing left for the current frame to do.

Try factorial(100000) in Node and it throws RangeError: Maximum call stack size exceeded. Try factorialTCO(100000) and — in a spec-compliant engine with real TCO — it would run in constant stack space. In practice, in every major JavaScript engine as of today, it still throws too.

What people usually miss

Watch out

• "It's in the spec" does not mean "it's in your runtime." V8 (Chrome, Node), SpiderMonkey (Firefox), and JavaScriptCore (Safari) have all either never implemented proper tail calls or shipped and then walked them back. Safari briefly supported it and it caused enough compatibility problems that relying on it is not safe practice today. Don't write recursive code assuming TCO will save you — it won't, on the JS you'll actually ship to.
• Deep recursion is a real risk in JS, full stop. If a problem is naturally recursive and the input size is unbounded (parsing deeply nested JSON, walking a huge tree), an iterative version with an explicit stack/queue is the safe choice, not "just write it tail-recursively."
• Rewriting a function to be tail-recursive is still worth doing for clarity and correctness even without the optimization — it forces you to make all the "carry-forward" state explicit as arguments (like acc above) instead of implicit in pending stack frames, which is often just cleaner code.

The genealogy: recursion needs a stack, and closures need scope

Every recursive call pushes a stack frame the same way every function call does — this is the same call stack that underlies how JavaScript executes any function, recursive or not. And the accumulator pattern above — carrying state forward as an argument instead of reading it from an outer variable — is the opposite move from a closure, which keeps state alive by capturing it from an enclosing scope rather than passing it explicitly.