Ask HN: ES6 javascript Generators+Promises async patterns | Hacker News Reader

Ask HN: ES6 javascript Generators+Promises async patterns

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' 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'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?

View on HN

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.

I'm assuming you've looked at 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.

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

even this point of synchronous appearance... isn't it misleading? the code is not executing synchronous. so why should the code look like something which is not?

Reply on news.ycombinator.com