All news
productcybersecurity

JavaScript Recursion Risk: Why TCO Can't Be Trusted

28 Jul 2026

The claim

A blog post titled "Your Recursion Is Lying to You", published on May 9, 2026, is making the rounds among JavaScript developers after being featured in both Node Weekly #624 and JavaScript Weekly on June 2, 2026. Its core argument: recursion in JavaScript is far more fragile than most developers assume, and the safety net many rely on—tail call optimization (TCO)—can't be trusted across runtimes.

The numbers behind the warning

The post backs its claim with concrete figures:

  • A recursive sum function crashes at a call depth of 100,000, hitting JavaScript's stack limits.
  • A naive fib(30) implementation triggers over 1,000,000 recursive calls.
  • fib(50) balloons to tens of billions of recursive calls—illustrating how quickly naive recursive algorithms can spiral out of control.

Why tail call optimization isn't the fix you think it is

ECMAScript 2015 formally specified proper tail calls in strict mode over a decade ago. In theory, this should let tail-recursive functions run indefinitely without growing the call stack. In practice, the report notes:

  • Most JavaScript runtimes do not consistently implement TCO, despite the spec.
  • Some engines shipped TCO support and later removed it due to performance regressions.
  • As of May 2026, developers cannot reliably count on TCO support across runtimes.
  • Even code carefully structured to be tail-call-optimized can still consume stack per call in many JavaScript environments—undermining the very safety developers assume they're building in.

The report does not specify which engines removed TCO support, nor which runtimes (V8, SpiderMonkey, JavaScriptCore, etc.) were tested to produce the stack-depth and call-count figures cited above. It also doesn't detail the hardware or environment used to reproduce the 100,000-depth crash.

Why founders should care

For teams building JavaScript or Node.js-based products, this is a reminder that recursive code paths carry more hidden risk than they might seem to:

  • If your product processes deeply nested data structures, recursive trees, or large-scale computations, it's plausible that stack-depth crashes could surface in production once inputs scale beyond what was tested in development.
  • Teams that rely on tail-call-optimized code for correctness or performance may be exposed to reliability risk they don't know about, since TCO support is inconsistent and not something you can safely assume is present just because your code follows the spec.
  • This is more likely to matter for performance-sensitive or data-heavy features—recommendation engines, tree traversals, parsers—than for typical CRUD applications, but the report doesn't quantify how common these failures are in production systems.

What teams might do about it

The report points to two practical directions rather than concrete fixes:

  1. Audit recursive functions for stack-depth risk, particularly in code paths that handle variable or unbounded input sizes, before scaling data-heavy features.
  2. Test recursion behavior directly on target runtimes rather than assuming ECMAScript spec compliance guarantees safe behavior in production.

The original post doesn't detail alternative techniques such as trampolining or iterative rewrites beyond acknowledging the underlying problem—so teams following up on this will likely need to research mitigation patterns separately.

The bottom line

There's no dispute in the available reporting about the core facts: stack limits are real, naive recursion scales badly, and TCO support is inconsistent across JavaScript runtimes. What's missing is engine-level specificity—which runtimes were tested, which shipped and pulled TCO, and what mitigation techniques work best. For founders shipping JS-based products with any recursive or tree-like data processing, this is a reasonably strong signal to test recursion limits directly rather than trust spec compliance alone.

Sources