I get asked this question a lot — I help maintain redux-saga.

I recently gave a talk where this question came up: https://youtu.be/uRbqLGj_6mI?t=2166

I’ve also imposed generators on a lot of colleagues.

I think they are mostly misunderstood and potentially in the realm of being “magical” — at least on the surface.

The reality is they are syntactic sugar on top of functions with recursive switch statements where each case is a yield point.

They aren’t that hard to grok — the syntax is mind bending. Having code that looks synchronous but behaves asynchronous is “magical.”

I think it does come down to that because everyone loves async/await even tho that’s just sugar on generators where each yield must be a promise.

Personally, I love redux-saga. It took me a little while to wrap my head around it (but 1/10th the amount of time as RxJS), but it is _really_ nice to be able to write complex async logic in synchronous-looking code that's also readable. (At least it was readable for me and the people on my team.) Whenever I had some weird async coordination problem that I needed to solve, I was _always_ able to solve it with redux-saga. I wish more people would use it.

I feel the same way which is why I decided to help maintain the project. Async flow control is very tricky even in js–land. Having watchers live inside of a while-loop is a powerful construct that lends itself to interest flow control patterns.

I'm also in the process of rebuilding redux-saga but without the redux part: https://github.com/neurosnap/starfx

It's still in alpha stage, but it is very reminiscent of redux-saga.

And then there's async generators...

Nothing other than they're one of the more esoteric and misunderstood features of the language.

It’s a great question, and for the folks who knows the answer of why generators misunderstood, they surely discovered this feature in the most unpleasant circumstances.

Generators were introduced during JavaScript’s awkward adolescence, where the cutting edge of ES6 was only possible through Babel (which was then called 6to5). They’re fantastic for turning array like classes into iterable collections. But that’s not what makes them bad.

For a time you had a perfect storm of JavaScript Hell. Promises were polyfilled and rewritten as generators to take advantage of the `yield` keyword. You’ll most likely find out about this trick at the least opportune time: while debugging an async redux action. Now every single stack trace is a high-stakes game of “detangle the Christmas lights!

This was truly a horrible time to be a front end developer. Not only did you have to transpile your code, you had to debug it through a source map wrung through Webpack’s module system. And while you’re picking through this mud ball of a web app, there’s a Super Senior Software Engineer giving a talk on the virtues of observable data management!

I’ve always suspected that these galaxy brain engineers are more like window washers on an ivory tower. And as for the rest of us, we’re just the code gnomes who are shrug when given triangular bricks until told how round bricks are actually better.

I know this is all hyperbole but the emotion is real. For every productive hour of work gained through a new and necessary features, engineers have lost 10-fold on the lesser well-thought out JavaScript. I’m not so sure that native observables will be any different.