I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.
If it's inconsistent, then people write a lot more tail calls and a lot more sites break on a lot more devices.
It doesn’t add up if V8 is withholding TCO under the guise that it would cause programmers to write stack overflow bugs unless a new proposed keyword for it gets added to the language. The truth currently is that V8 itself has a stack overflow bug in its omission of TCO, it wouldn’t be right to shift the responsibility for that to the JavaScript programmers. But you’re right, unfortunately the JavaScript programmers are the ones who have to deal with the consequences of V8’s spec non-compliance which causes the stack to overflow when it shouldn’t.
