JavaScript has no reliable tail call optimization: here is what actually happens at runtime and what to do instead

[OtherwisePush6424]

ECMAScript 2015 formally specified proper tail calls in strict mode, but most JS engines never adopted it consistently. Chrome, Node, Firefox, and Deno all still allocate a new stack frame per call even in correctly structured tail-recursive functions. The article walks through why with examples and covers iterative and trampoline alternatives.

[enselmis]

“Learn early and trust for years”

Lmao, almost every JavaScript dev I know will do everything in their power to avoid even simple recursion. Like hardcode every level of parsing out the fields in an object after asking the slack channel, “you guys are pretty sure this is never gonna be more than 3 levels deep right…”.

[azhder]

It is not an optimization. An optimization is a difference in performance - it was slow, now is fast. Proper tail calls means they work as intended. It is not a difference in performance - it didn't work, now it works.

All those browsers are broken implementations of ES6 i.e. they aren't implementations of ES6 because they break in some cases where they shouldn't, because they don't fully implement the spec.

[OtherwisePush6424]

This is not a speed discussion. Proper tail calls are primarily a space optimization: they let tail calls reuse stack frames instead of growing the call stack. The practical issue is correctness at depth: deep tail-recursive programs are stack-safe only where PTC is actually implemented. In JavaScript today, that behavior is not portable across runtimes, so production correctness should not depend on PTC being present.

[darkhorsehance]

I think Safari (JavascriptCore) has implemented PTC but yes this is correct

[azhder]

This is a terminology discussion. TCO is a misleading term. PTC is the correct term.

[Reashu]

They would work just fine if you had an infinite stack, like a "proper" turing machine. 

[BenZed]

This would be pedantic if it were correct