[dimitropoulos]

> Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers.

I'm getting so tired of hearing this. I loved the article and it's interesting stuff, but how many more decades until people accept generators as a primitive??

used to hear the same thing about trailing commas, destructuring, classes (instead of iife), and so many more. yet. generators still haven't crossed over the magic barrier for some reason.

[horsawlarway]

There just aren't that many spots where the average js dev actually needs to touch a generator.

I don't really see generators ever crossing into mainstream usage in the same way as the other features you've compared them to. Most times... you just don't need them. The other language tools solve the problem in a more widely accessible manner.

In the (very limited & niche) subset of spots you do actually need a generator, they're nice to have, but it's mostly a "library author" tool, and even in that scope it's usage just isn't warranted all that often.

[no_wizard]

mainly because they messed up on implementation, in two ways. This is of course my opinion.

The first being `.next()` on the returned iterators. If you pass an argument to it, the behavior is funky. The first time it runs, it actually doesn't capture the argument, and then you can capture the argument by assigning `yield` to a variable, and do whatever, but its really clunky from an ergonomic perspective. Which means using it to control side effects is clunky.

The second one how it is not a first class alternative to Promise. Async Generators are not the most ergonomic thing in the world to deal with, as you have the issues above plus you have to await everything. Which I understand why, but because generators can't be used in stead of Promises, you get these clunky use cases for using them.

They're really only useful as a result, for creating custom iterator patterns or for a form of 'infinite stream' returns. Beyond that, they're just not all that great, and it often takes combining a couple generators to really get anything useful out of them.

Thats been my experience, and I've tried to adopt generators extensively a few times in some libraries, where I felt the pattern would have been a good fit but it simply didn't turn out most of the time.

[cowboyd]

I think writing an effect library yourself is a tough ask, but some of them have gotten really, really good. And they get you things that are simply not possible with promise. Check out Effection if you want a more vanilla javascript syntax, or Effect if you're really into expressing things functionally.

[gbuk2013]

It is a specialised instrument but a useful one: batch processing and query pagination are first class use cases for generators that can really simplify business logic code. Stream processing is another and in fact Node.js streams have had a generator API for several releases now.

[yeittrue]

Generators peaked in redux- saga and thunk days before we had widespread support for async/await.

You're right, mostly pointless syntax (along with Promise) now that we can await an async function anyway, especially now with for .. of to work with Array methods like .map

But there are still some use cases for it, like with Promise. Like for example, making custom iterators/procedures or a custom delay function (sync) where you want to block execution.