[distracteddev90]

Any chance Rdb plans to support a traditional callback style interface for those of us that prefer to stay away from promises?

[lroal]

My plan was to stick to promises only. Unless there are lots of lots of developers that really wants callbacks.

[phpnode]

please stick with promises. Promises are the only sane way to deal with async in JS. With people starting to use async/await they become even more compelling.

The people who defend callbacks either don't understand the benefits that promises provide, don't know about async/await or are suffering from stockholm syndrome.

Callbacks do not pass the reversibility test. If everyone had started out with promises and / or async/await, and someone proposed callbacks as a way to deal with this instead, they'd be dismissed as a fool. They're an accident of history and we should forget about them as quickly as possible.

[doublerebel]

Callbacks allow await/defer in Iced CoffeeScript, not to mention the other async libs as stated above.

Promises don't really offer any benefit to program structure overall, generally devs just end up creating long chains of anonymous functions rather than long nests of anonymous functions. Promises actually discourage flat code (and functional programming) for that reason. I understand they seem attractive but become a hack in complex situations.

[phpnode]

> Callbacks allow await/defer in Iced CoffeeScript

Not the same thing as in ES6, also that project is totally dead.

> generally devs just end up creating long chains of anonymous functions rather than long nests of anonymous functions

Not true in my experience, also not required at all when using async / await.

> Promises actually discourage flat code (and functional programming) for that reason.

This is really not true, Promises are functional and composable, callbacks are imperative.

> I understand they seem attractive but become a hack in complex situations.

Just no. Callbacks lead to terrible "solutions" like caolan/async, callbacks make refactoring extremely awkward.

Callbacks don't even get to claim better performance, because they require a load of internal hacks in node/io.js to maintain state.

With async/await in the picture, callbacks so totally inferior I can't believe someone would attempt to argue otherwise.

[jermo]

I might be missing something but why would you prefer callbacks over promises? I've heard of 'callback hell' but never heard of 'promise hell'.

[distracteddev90]

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed.

Both interfaces can be abused to give you an ever growing indent and give the appearance of "callback hell"

Both interfaces can be use elegantly to help you reason about your code, make it easy to follow, and handle errors centrally.

Only one is supported natively by node.js and is the standard async interface for 90% of node.js's libraries: Callbacks.

Also, regarding "callback hell", a straw-man argument against callbacks, I highly suggest reading http://callbackhell.com/

[jermo]

Oh ok, was just wondering about your reasons and that clears things up. That's a good read as well. But I think promises give you a way to compose them in a way that callbacks don't. With promises you can call easily call a function when multiple promises are fulfilled.

[distracteddev90]

Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow.

By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples).

[0] https://github.com/caolan/async

[1] https://github.com/creationix/step

[2] https://github.com/caolan/async#control-flow

edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-flow breaks down.

[blablabla123]

At least a part of promises, the then function, is standardized through Promises/A+. This way you can easily combine different promise libraries to do things like:

- sequential execution

- parallel execution and wait for all of them to finish

- automated error handling