[zipfle]

I know I'm in the minority about this, but I still prefer callbacks. In one common case, you're only doing one or two async things in a given area of the code, and in that case the async primitive you choose doesn't really matter. In another common case, you're doing a lot of async things that depend on each other's outcomes. In that case, I find that it's easier to build a reusable pattern for handling the specific type of async interaction you have using callback-based functions, whereas with promises and async/await, you tend to try to write straight line code that can't be reused and hides the asynchrony in a way that makes it difficult to debug.

[NathanKP]

I'm just too hooked on the async.auto() pattern to give up callbacks. The ability to break a large flow down into functions and then use a dependency based structure to automatically execute the flow with the most optimal concurrency is incredible. And the resulting code is very clean, with each functional step in the flow living on the same indent level. Refactoring and adding new steps is very easy as you can just add a new dependency to one of the existing functions or add a new function that depends on one of the other functions.

https://caolan.github.io/async/docs.html#auto

[Matthias247]

That looks interesting - as long as you stay in JS land. Once you move into typescript this kind of system will be impossible to typecheck. Promises and their compositions will typecheck just naturally compared to that.

[NathanKP]

Yep, there is the autoInject which injects previous dependent functions return values as parameters instead of as properties of a context object, so that may help some, but it still breaks typechecks.

I wish that promises had a concept similar to this. It's simply too annoying for me to manually refactor a bunch of Promise.all() calls to manually adjust the concurrency of the logic flow compared to using the dependency pattern of async.auto().

And based on what I've seen this is a common problem in both async functions, generators, and promises. Since it is difficult to properly execute a tree of functional steps with the maximal concurrency I see code all the time which just runs async functions or promises in a series instead of taking advantage of the ability to concurrently execute two branches of the tree at the same time.

[elithrar]

Have you looked at http://bluebirdjs.com/docs/api/promise.map.html - which allows you to control the concurrency of Promises easily?

[samsonradu]

Here you can read about the advantages of using Promises, it s very interesting, though a bit long. https://blog.jcoglan.com/2013/03/30/callbacks-are-imperative...

Promises are easier to compose because you can pass them around as values. Meanwhile callbacks are used only for their side-effects, they do not return anything.

[nol13]

Good not just me. I guess at this point I'm kind of ambivalent, but sometimes still think async.js is a lot easier to reason about.

Have not yet moved to async/await though.