
Ask HN: ES6 javascript Generators+Promises async patterns - unusximmortalis
is it just me or indeed these async patterns based on ES6 Generators+Promises are pretty hard to deal with? I find them way more complex then the good ol&#x27; callbacks pattern; and by complex I mean hard to understand, hard to write, hard to maintain, thus not more productive. I like a lot the KISS principle and I find this is not even close to that. don&#x27;t we all want to move into a better direction? to me this is not doing that. 
is it just me having this opinion? am I getting old here and rusty and not open to new better ways of the new age?
also, can you recommend a good source which explains these patters?
======
lollipop25
Promises alone, good for me. Promises + generators, they just created a
monster. I'll probably be sticking to just promises for a while.

JavaScript is becoming terrible these days with all these foreign concepts
being pulled in. It's not like the language doesn't work without them. It even
gets better, ES7 has the async keyword that's totally different from
generators, but is geared to do the same thing. So you now have 4 ways to deal
with async stuff: vanilla callbacks, promises, generators and async functions.

\---

On a side note, the people who lead JS included `const` in the spec. Now
people are using `const` to denote value holders that won't and should not
change values, happy ever after right? Wrong. The same people that are leading
JS are making fun of people using `const`, saying that you're probably brain-
dead to need `const` to keep you safe.

That's the kind of people "leading" JS.

------
pedalpete
I'm assuming you've looked at
[https://www.promisejs.org/generators/](https://www.promisejs.org/generators/)

I somewhat agree, prefer callbacks to promises, generators as I see it give
you more control of what happens within a promise and how to deal with
multiple promises being returned.

The danger I see with promises is they can be used incorrectly. The project
I've taken over at work, the developer used a promise as a timer and littered
watching the same promise all over the code using ```
Promise(functionToResolve).then(function()... ```

This means we never know where a function is being called from. I don't think
you could do something like this with callbacks, instead you'd have to do ```
function(callback(){ // trigger your other methods here } ```

but maybe I'm wrong, I never would have expected somebody to use promises in
the way they are used here.

Like'em or not, they are here to stay, and some people like the more
synchronous appearance of them and I believe when dealing with an array of
promises, generators will provide more fine-grained control.

Keen to hear others thoughts though.

~~~
lollipop25
> This means we never know where a function is being called from.

Not really. Chrome dev tools has an "async" option which allows the stack
trace to follow through async calls. You will see the async caller instead of
the async execution mechanism in the stack. Further, you can black-box
frameworks so you only see your code.

> The danger I see with promises is they can be used incorrectly.

The real danger of promises is the different implementations that existed
beforehand. For instance, jQuery promises weren't standards-compliant. Their
implementation of `then` (which came from `pipe`) wasn't the same as the
native one. Getting used to one, you'll easily write wrong code for the other.

> generators will provide more fine-grained control.

Depends. It's a foreign concept in JS, making it harder to follow as opposed
to promises which are nothing more than stateful objects. Also, one's mental
model will change with generators. One has to look out for that tiny `*` to
know the code is "generator friendly".

