I already told you, I liked your article. I said it was great. You get a trophy, smart person.
My gripe is a lack of disclaimer. There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world.
The trampoline is a bad idea in practice. I can't show you an out of memory error or lack thereof. The code in your article hard locked the dev tools which is much much worse than throwing an error.
Since the trampoline is a bad idea, the solution to your stack overflow errors needs work. It follows that with no solution, then the ycombinator itself is inappropriate. It shouldn't be hard for you to admit that, being as smart as you are. All I'm asking is that you mention that more prominently in your otherwise great article.
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.
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.
So we start out with an attempt to build an anonymous recursive function. That's cool I suppose. But doing it in a language like javascript (or java)? It turns out that tail recursion == stack overflow. Not daunted, the plucky author decides that we can solve this particular issue by creating a closure over stack variables and put them on the heap instead!
You know, if you want to use Haskell, use Haskell. Trying to shoehorn this stuff into languages designed for loops instead of recursion just means impressionable JS developers are going to see this and rush out to implement it in some project to prove how smart they are. Then everyone suffers. The implementation is slower because it goes to heap. The memory usage explodes because it goes to heap.
Purely for illustration of a Y combinator, this is great. But there should be a big red warning somewhere on the page as a reminder of the downsides of this approach.
Web ads are the new spam. In response to email spam, all ISPs blocked port 25 by default. ISPs will ultimately do the same to web ads using traffic prioritization techniques like PiHole.
Users in general aren't sophisticated enough to do this themselves. ISPs will offer it for a price and users will pay more to have ad free internet while simultaneously benefiting ISPs with bandwidth reductions. Some ads will be allowed through of course, but with significant costs associated with the advertising, the volume will be reduced significantly, like the difference between spam email volume vs that of postal junk mail.
If big sites like Facebook decide to fight it in a cat and mouse game, ISPs can hit them with advertising fees directly or throttle their traffic in retaliation for cheating the system. If browsers like FireFox try to defeat it by doing DNS over HTTPS, then ISPs can funnel 1.1.1.1 directly into the trash. AT&T did this and said it was an accident. I'm sure it was more like a test. They are aware of what underhanded scheme FireFox is up to. Mozilla isn't fooling anyone with their "security" cover story.
Ultimately, this is going to end badly for advertisers. All ISPs block port 25. In < 5 years, all ISPs will provide PiHole functionality on their networks. "Net Neutrality" is gone. This is going to be glorious. Thank goodness for the FCC making this protection available to the masses.
My gripe is a lack of disclaimer. There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world.
The trampoline is a bad idea in practice. I can't show you an out of memory error or lack thereof. The code in your article hard locked the dev tools which is much much worse than throwing an error.
Since the trampoline is a bad idea, the solution to your stack overflow errors needs work. It follows that with no solution, then the ycombinator itself is inappropriate. It shouldn't be hard for you to admit that, being as smart as you are. All I'm asking is that you mention that more prominently in your otherwise great article.