3 ms·

I'm assuming you've looked at https://www.promisejs.org/generators/ https://www.promisejs.org/generators/ I somewhat agree, prefer callbacks to promises, gene

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 11y ago
> 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".
unusximmortalis 11y ago
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?

lollipop25 11y ago

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

unusximmortalis 11y ago

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?