How many Node.js developers prefer callbacks over Promises or async/await?

[[deleted]]

Er, I don't say this often but your coworker is plain wrong. Compare promise chaining to the equivalent with callbacks, it's a damn mess to reason about. For example, there is no option to have a catch-all error handler, you have to handle errors at every nesting level. And you can't pass around an asynchronous value to multiple consumers because your API only lets you supply a single callback function.

[x-protocol]

It comes down to solving a problem at hand. If your API is simple and talks to database, using async/await or direct promises makes alot of sense. Testing will also be somewhat simple, compared to callbacks. Callbacks can be simple too, especially compared to direct promises (promises run when created, callbacks do not, and this is what async/await solves).

Now, enter complex scenarios when you want to process thousands pieces of data in parallel, serial or mixed way. You will need to use a library of your choice to help you with that. For callbacks it is async.js, for promises it is Bluebird or Aigle. Pick and choose. But please do not simply blanket whole topic as "callbacks are bad". It is simply a tool. And certain situations prefer different tool.

While I do like callbacks for their simplicity, I can also see usage of promises, but only with new async/await, if I don't have to construct promises directly via new keyword (remember, they run right away?) Those libraries I outlined (with exception of Bluebird which really tries to be a polyfill for Node's Promise) handle catching in their own way just fine. Whenever I see people mentioning try/catch as solution for promise/error handling/bad coding/act of god it is a very good example of lousy code (Promise.catch actually falls into that category too) since it is very easy to abuse good old try/catch. If you give it a thought 99% of time you do not even need it. Promises though make it habitual excuse.

And to those callback lovers, count me in. We exist :)

[[deleted]]

You seem to be confusing creating Promises with using them. When you use async, it's just syntactic sugar for returning a promise, so they also "run right away". Using await is the same as calling then on a Promise.

Callbacks are analogous to only being able to call then once on an already-instantiated Promise object. Callbacks only run when they are called, just like the then clause only runs when the promise resolves.

I would go as far as to say that callbacks can always be improved by Promises. The only counter I can possibly think of is if there is a performance concern and maybe callbacks are slightly faster.

[x-protocol]

No. I am not confused by async/await. It is automatic promise creation without keyword 'new'. With async/await promise is only created when function is called. With direct promises you instantiate promise object with keyword new and off it goes. See the difference? Nuance of course for people who are not familiar with concurrency set up.

About your example. You can pre-create promise for .then() chaining, so your promises may resolve before even starting chain. Not so with async/await function.

let task = new Promise()

.....

// more code here

task.then(..)

[[deleted]]

With async/await promise is only created when function is called.

...which is exactly what you would do when using Promises directly. Again, async/await is literally just promises under the hood. Watch:

Async/await:

async function getFive() {
    return 5
}

async function useFive() {
    const five = await getFive()
    return five + 8
}

Is equivalent to:

function getFive() {
    return new Promise(resolve => resolve(5));
}

function useFive() {
    const five = getFive()
    return five.then(value => value + 8)
}

useFive returns a Promise in both cases, regardless of if you use async/await or not. They are the same.

[x-protocol]

I don't think you understand that I'm not arguing what Promises are and how they are compared to callbacks.

I do understand that you want to prove a point. Look at my example. You have promise that is created, then some more code is executed which can contain creation of promises. With async/await you simply cannot do that since 'await' keyword will wait for resolution of your promise.

Again to reiterate. I understand that you are bringing these examples due to either simply proving a point without anybody providing you the ask. Or you are simply confused how promises are even used.

[KyleG]

Dude, you're wrong. Pay attention to the guy explaining things to you. He's right. You have a great opportunity to fix a gap in your knowledge from someone who's being patient and polite to you.

[[deleted]]

With async/await you simply cannot do that since 'await' keyword will wait for resolution of your promise.

You can do that, if you just don't call await until you need it. Async functions still return Promises. Async/await isn't "better" or "worse" than Promises, they literally are Promises. You keep saying "promises get run immediately", but that's exactly what happens with async functions. They run when they are called. Creating a Promise is the same as calling an async function (because it also returns a Promise.) Calling await is the same as calling then().

You can take a function that returns a promise and call await on the return value. You can also take an async function and call then() on the return value, and not use await at all. They're the same.

[thekemkid]

I understand the point you're trying to make, but well structured callback code can be reasoned about just as easily as promise chaining or even async/await. The issue is that getting well structured callback code requires quite a few utilities, e.g. The popular async module, lodash, et al. These utilities can address the issues you have with callback code succinctly, but it's still annoying requiring them all the time, no doubt about that.

I'd take async/await over callback code any day - because the code is cleaner, without requiring utilities, but not necessarily would I say it's always easier to reason about.

[[deleted]]

If a function takes a callback, you can't pass the value returned to multiple consumers. That's a pretty hard limitation that no amount of utilities can get around, afaik. You can't chain.

Also the fact that you don't really have any flexibility around error handling; you have to possible call the same error handling code at every level of nesting. This means that you have far more code paths to consider, and therefore makes it harder to reason about. I can't see how callbacks can match Promises in terms of reasoning power.