Tail calls

A tail call is the last thing a function does

You already know from Stack overflow that ordinary recursion can run out of call stack. This lesson asks a more precise question: when a function calls another function, can the caller leave before the callee starts?

That definition is about the source code. A proper tail call, or PTC, is the stronger engine behavior: the engine does not keep adding caller frames for qualifying tail calls. ES2015 specifies that behavior for strict-mode tail calls, but only Safari's JavaScriptCore ships it in practice today.

We will keep the scope narrow. Advanced recursion covers recursive problem solving. The neighbouring Stack overflow lesson covers limits and explicit-stack iteration. The stack-frames lesson covers frame contents. Here we focus on tail positions, ES2015 PTC, and portable workarounds.

Start with tiny code. Line 9 is a tail call because direct returns exactly what finish returns. Line 13 is not a tail call because addAfter must still concatenate "value ". Line 17 looks surprising: if the right side of || runs, that call's result becomes the whole returned value, so the spec treats it as tail position.

1"use strict";2 3function finish(label) {4  console.log("finish " + label);5  return label;6}7 8function direct() {9  return finish("direct");10}11 12function addAfter() {13  return "value " + finish("add");14}15 16function rightSideTail(ready) {17  return ready || finish("right");18}19 20console.log(direct());21console.log(addAfter());22console.log(rightSideTail(false));

The output is ordinary JavaScript: finish direct, then direct, then finish add, then value add, then finish right, then right. Runtime output does not tell you whether an engine reused a frame; it only proves the calls ran in that order.

The ECMAScript spec's static semantics are precise. It checks strict mode first, then asks whether the specific call appears in a return expression's tail position. For short-circuit expressions, it recurses into the right operand of ||, &&, and ??, not the left operand.

ES2015 added a semantic requirement called proper tail calls. In plain words: for a strict-mode call in tail position, the engine must release or reuse the current execution context before invoking the target. The spec names this operation PrepareForTailCall.

Two details matter. First, the spec only defines tail-position calls for strict-mode code. That avoids old caller-chain features from sloppy mode. Second, PTC changes stack growth, not the final value. A PTC engine and a non-PTC engine should both compute the same sum; they differ in whether deep tail recursion keeps piling frames.

1"use strict";2 3function countDown(n) {4  if (n === 0) return "done";5  return countDown(n - 1);6}7 8function sumTo(n, acc = 0) {9  if (n === 0) return acc;10  return sumTo(n - 1, acc + n);11}12 13function trampoline(thunk) {14  let current = thunk;15  while (typeof current === "function") current = current();16  return current;17}18 19function countDownThunk(n) {20  if (n === 0) return "done";21  return () => countDownThunk(n - 1);22}23 24function sumThunk(n, acc = 0) {25  if (n === 0) return acc;26  return () => sumThunk(n - 1, acc + n);27}28 29console.log("node", process.version);30console.log("v8", process.versions.v8);31try {32  console.log("plain-countdown", countDown(100000));33} catch (error) {34  console.log("plain-countdown", error.name);35}36try {37  console.log("tail-sum", sumTo(100000));38} catch (error) {39  console.log("tail-sum", error.name);40}41console.log("trampoline-countdown", trampoline(() => countDownThunk(100000)));42console.log("trampoline-sum", trampoline(() => sumThunk(100000)));

node v22.x
v8 12.4.x
plain-countdown RangeError
tail-sum RangeError
trampoline-countdown done
trampoline-sum 5000050000

That is why you should not write production JavaScript that depends on PTC unless your supported engine list is explicit and tested. If your code must handle arbitrary depth, use a portable pattern.

WebKit's JavaScriptCore ships proper tail calls and documents the memory benefit: tail-deleted frames do not remain on the stack. It also documents the debugging problem and its ShadowChicken machinery, which reconstructs useful call history while the debugger is active.

V8 implemented and staged ES2015 proper tail calls, then moved away from shipping them. The V8 team wrote that elided frames make debugging and error.stack less useful, and that always-on shadow stacks are too expensive. Mozilla and Microsoft committee members co-championed an explicit syntactic opt-in instead.

The accumulator version of sumTail puts the pending addition into the argument before the recursive call. Line 5 returns the recursive call directly, so a PTC engine can hand off and reuse the current frame. V8 in Node does not, so the ordinary stack still grows.

1"use strict";2 3function sumTail(n, acc = 0) {4  if (n === 0) return acc;5  return sumTail(n - 1, acc + n);6}7 8console.log(sumTail(4));Run

This is a teaching model, not a browser inspector. The code really computes 10; the side-by-side counters label what a proper-tail-call engine may do compared with what V8 does today.

A thunk is a zero-argument function that delays work. A trampoline is a loop that keeps calling thunks until it gets a plain value. Instead of growing the JavaScript call stack, every recursive step returns to the same loop.

1function trampoline(thunk) {2  let current = thunk;3  let hops = 0;4  while (typeof current === "function") {5    current = current();6    hops += 1;7  }8  return { value: current, hops };9}10 11function sumThunk(n, acc = 0) {12  if (n === 0) return acc;13  return () => sumThunk(n - 1, acc + n);14}15 16const result = trampoline(() => sumThunk(4));Run17console.log(result.value);18console.log(result.hops);

The code prints 10 and then 5. The extra hop is the initial thunk passed to trampoline. For n = 100000, the same shape stays stack-safe in Node where plain tail recursion throws.

Now run both versions where you are reading. The plain version is strict and tail-recursive. The trampoline version uses thunks. The output is labelled your browser because Safari can differ from Chromium and Firefox.

1"use strict";2 3function countDown(n) {4  if (n === 0) return "done";5  return countDown(n - 1);6}7 8function trampoline(thunk) {9  let current = thunk;10  while (typeof current === "function") current = current();11  return current;12}13 14function countDownThunk(n) {15  if (n === 0) return "done";16  return () => countDownThunk(n - 1);17}

Use small numbers first, then raise the input. If the plain call throws RangeError, the trampoline should still return done. If the plain call returns too, either the input is shallow enough or your engine implements PTC for that case.

The syntactic tail calls proposal tried to make the handoff explicit. The commonly shown spelling was return continue f(x). That would let developers opt into missing caller frames and let engines reject code that looked like a tail call but could not be guaranteed.

1function factorial(n, acc = 1) {2  if (n <= 1) return acc;3  return continue factorial(n - 1, acc * n);4}

It is still useful vocabulary. When someone says “syntactic tail calls,” they mean an explicit source-level marker, not the silent ES2015 PTC rule.

Most application code should stay readable. If a tree is shallow and trusted, ordinary recursion is fine. If the depth is user-controlled, generated, or unbounded, do not depend on PTC. Choose a loop, an explicit stack, or a trampoline.

1function visitMenu(node, path = []) {2  const nextPath = path.concat(node.label);3  if (node.children.length === 0) return [nextPath.join(" > ")];4  return node.children.flatMap((child) => visitMenu(child, nextPath));5}6 7const menu = {8  label: "Home",9  children: [10    { label: "Courses", children: [{ label: "JavaScript", children: [] }] },11    { label: "Pricing", children: [] },12  ],13};14 15console.log(visitMenu(menu).join(" | "));

Line 4 recurses inside flatMap. That is clear for small menus, but it is not a portable stack-safety strategy for a huge user-generated tree. For deep data, rewrite the traversal with your own stack of nodes, or use a trampoline if keeping a recursive shape is valuable.

• Measure first when performance is the reason for changing code.
• Choose loops or explicit stacks for untrusted depth.
• Use trampolines when the recursive shape is important and allocation overhead is acceptable.
• Do not rely on PTC unless your supported engine matrix proves it.

Common misconceptions

Practice exercises

"use strict";
function finish(label) {
  console.log("finish " + label);
  return label;
}
function notTail() {
  return "value " + finish("add");
}
console.log(notTail());

function trampoline(thunk) {
  let current = thunk;
  let hops = 0;
  while (typeof current === "function") {
    current = current();
    hops += 1;
  }
  return { value: current, hops };
}
function sumThunk(n, acc = 0) {
  if (n === 0) return acc;
  return () => sumThunk(n - 1, acc + n);
}
console.log(trampoline(() => sumThunk(4)).hops);

function factorial(n, acc = 1) {
  if (n <= 1) return acc;
  return continue factorial(n - 1, acc * n);
}

function collectLabels(root) {
  const stack = [{ node: root, path: [] }];
  const labels = [];
  while (stack.length > 0) {
    const { node, path } = stack.pop();
    const nextPath = path.concat(node.label);
    if (node.children.length === 0) labels.push(nextPath.join(" > "));
    for (const child of node.children) stack.push({ node: child, path: nextPath });
  }
  return labels;
}

Use the source-position rules first, then the engine-support facts.

Key takeaways

• A tail call returns another call's result directly; work after the call makes it non-tail.
• ES2015 proper tail calls are specified for strict-mode tail positions, but most engines do not ship them.
• Safari's JavaScriptCore is the notable shipping browser implementation; V8/Node and SpiderMonkey should be treated as non-PTC.
• Trampolines, loops, and explicit stacks are the portable answers for deep recursion today.