3 ms·

I think there are use cases where Promise and async/await makes sense, for example transactional SQL, so you can break up the transaction into many simple queri

by z3t4 8y ago

I think there are use cases where Promise and async/await makes sense, for example transactional SQL, so you can break up the transaction into many simple queries instead of one huge complex query and without the added boilerplate from the callback pattern. But when you add Promises, they tend to spread. A middle ground is to have both Promise and callback, eg. if(!cb) return promise. Another gripe with Promise's is that "soft" errors are treated the same as catastrophic errors.

Klathmon 8y ago
While I agree that there is room for both (callbacks make sense in some areas, promises/async/await in others). I feel that promise-based async should be the default, since it provides so many additional benefits. >A middle ground is to have both Promise and callback, eg. if(!cb) return promise. This works in many cases, but becomes ugly in some. The 2 ways of working have subtle differences (callbacks and promises both trigger at different times, and there is some interplay with "microtasks" and queues and schedules and other things that make some situations hairy). There's also the problem of Promises being hard to use when additional closures are involved (it's why `.forEach` sees much less usage in async/await codebases, because it's a lot more cumbersome to "wait" on iterating over an entire array with `.forEach` because the inner `await` can't escape the function in `.forEach`.) So most users will end up choosing one or the other for the whole library, and at that point why not just have them be 2 different libraries? It also makes documentation harder, and makes the implementation of the library a lot more complex (now it needs to do EVERYTHING in both a promise-friendly way, and a callback-friendly way), and some things just can't be easily split (how do you support both async iterators and node.js event streams at the same time in the same interface?)
- z3t4 8y ago
  One strategy is to be adapter friendly by sticking to conventions. By adapter friendly i mean promisify and event emitter to async iterator adapter. And vice versa. And by conventions i mean things like error first. Then it might be possible to just have a .promises property that expose the api via the adapter. So that you can support many paradigms, with minimal changes to the code base. With paradigms I mean different ways to work with async, there are probably 20 different ways that I know of if I also include ways how to run things in parallel. My personal opinion is that promises should have stayed in userland (not in ES spec) to give competing standards a chance to compete. Those wanting async/await patterns could have used co routines/generators.
tlrobinson 8y ago
When you add asynchronous operations, whether they use promises or callbacks, they tend to spread beacause any consumer of an async operation probably needs to be async itself. That’s not specific to promises. If you return a promise you don’t really need to support a callback because you can just call .then on the promise with a callback. i.e. func().then(result => { // success }, err => { / error }) Is equivalent to func((err, result) => { if (err) { // error } else { // success } }) IMHO promise-based APIs are strictly better than callback/“errback” style APIs for many reasons, async/await support in the language being the nail in the coffin.

by z3t4 8y ago

Klathmon 8y ago

While I agree that there is room for both (callbacks make sense in some areas, promises/async/await in others). I feel that promise-based async should be the default, since it provides so many additional benefits. >A middle ground is to have both Promise and callback, eg. if(!cb) return promise. This works in many cases, but becomes ugly in some. The 2 ways of working have subtle differences (callbacks and promises both trigger at different times, and there is some interplay with "microtasks" and queues and schedules and other things that make some situations hairy). There's also the problem of Promises being hard to use when additional closures are involved (it's why `.forEach` sees much less usage in async/await codebases, because it's a lot more cumbersome to "wait" on iterating over an entire array with `.forEach` because the inner `await` can't escape the function in `.forEach`.) So most users will end up choosing one or the other for the whole library, and at that point why not just have them be 2 different libraries? It also makes documentation harder, and makes the implementation of the library a lot more complex (now it needs to do EVERYTHING in both a promise-friendly way, and a callback-friendly way), and some things just can't be easily split (how do you support both async iterators and node.js event streams at the same time in the same interface?)

z3t4 8y ago
One strategy is to be adapter friendly by sticking to conventions. By adapter friendly i mean promisify and event emitter to async iterator adapter. And vice versa. And by conventions i mean things like error first. Then it might be possible to just have a .promises property that expose the api via the adapter. So that you can support many paradigms, with minimal changes to the code base. With paradigms I mean different ways to work with async, there are probably 20 different ways that I know of if I also include ways how to run things in parallel. My personal opinion is that promises should have stayed in userland (not in ES spec) to give competing standards a chance to compete. Those wanting async/await patterns could have used co routines/generators.

tlrobinson 8y ago

When you add asynchronous operations, whether they use promises or callbacks, they tend to spread beacause any consumer of an async operation probably needs to be async itself. That’s not specific to promises. If you return a promise you don’t really need to support a callback because you can just call .then on the promise with a callback. i.e. func().then(result => { // success }, err => { / error }) Is equivalent to func((err, result) => { if (err) { // error } else { // success } }) IMHO promise-based APIs are strictly better than callback/“errback” style APIs for many reasons, async/await support in the language being the nail in the coffin.