[danjoc]

Why don't we just illustrate the problem using the code from the article?

https://jsfiddle.net/q59Ljeu7/

A loop is not just fewer LoC and easier, it is orders of magnitude faster than the ycombinator decoupled trampoline. The first alert is nearly instant. The second one takes almost a minute. My chrome dev tools are hard locked waiting for the ycombinator to finish.

This is not something I would encourage JS devs to use in practice.

[braythwayt]

Well, refactoring isEven or exponentiation to a loop is faster. But wait, you know what's even faster? Using built-in math primitives.

I wrote an entire article about refactoring tail-recursion to iteration and linked to it in TFA. I've also written a Scheme interpreter that can perform this optimization for certain functions on-the-fly. But arguing that the code is slow is missing the point by a country mile, and then some. The article is not arguing that the code is fast, or that you should always do this. I find it amazing that every time a programming technique is discussed, people want to worry about whether it belongs in production.

Is there no recreational programming any more? Or is it all about shipping the next app to deliver food by electric scooter? My world would be depressingly boring if the only things I thought about were the things I use at PagerDuty every day.

Now as to what I asked you about:

What you said was that this implementation leaks memory in such a way that using the trampoline it trades a stack overflow for an out-of-memory error.

I wish to understand that problem. Specifically, how does the decoupled trampoline leak memory?