[danjoc]

Going out to main memory is orders of magnitude slower than hitting cache. Even a stack overflow would be preferable to debug vs an out of memory error. At least with the stack overflow, the stack trace pinpoints the problem.

Like I said, I have no problem with this article as an illustration of a ycombinator for JS devs. The problem is it does not warn them sufficiently of the very major drawbacks in using it. This is why we have Gate's law; Developers using inefficient constructs because they're neato.

[braythwayt]

Well, given that the post links to two different discussion forums, I attest that it’s not my responsibility to outline every single consideration of every single technique, nor is it my responsibility to include the entire syllabus of computer science to explain the background.

Instead, I outsource that to people like you. You voice your concerns here, and people can read them and make up their own minds.

Speaking of making up their own minds, please explain in more detail how the trampoline’s memory consumption grows unboundedly, to the point where it could cause an out-of-memory error. That would be most interesting for the community to ponder.

[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.