The Curious Case Of Callbacks Vs ES6 Promises

Introduction

Hi everyone! Feels nice to be back with one more write-up on C# Corner.

The title over here has totally summed up my views regarding the two most fundamental concepts in the world of JavaScript prior to writing this piece.

Got to know from a lot of sources over the web about the good things before bringing these two concepts to the table. But most of them ended up proving to me that both of them do the same thing under the hood. After investing some more time to eke out any differences, I somehow got a near to convincing answer.

Let’s try to throw some light on the same here.

Callbacks

Callbacks are plain JavaScript functions that execute after completion of an asynchronous/non-blocking operation. Since these asynchronous operations (example Database interactions/API calls) usually take some time to finish, in most of the cases, callbacks provide the means to notify the end-user upon their completion. A general way of making use of callbacks is provided below.

someAsyncOperation(args, callbackFn() {
// some code here
});

Here, ‘callbackFn’ is the callback function that gets into the action as soon as ‘someAsyncOperation’ completes, and does some kind of notifying or follow-up work.

Example

Notifying the user that the operation is complete.

Promises

The ES6 update to JavaScript brought with it a ton of cool new features and abstractions over some redundant pieces of functionality which required all those truckloads of lines of code to be written in Vanilla JavaScript.

One of them was the introduction to the concept called Promises. Promises are similar to callbacks in a way that they look after an asynchronous operation’s execution flow. Given below is a general representation of how promises operate.

var somePromise = new Promise((resolve, reject) => {
//some async operation
resolve(response) // if the async request completes successfully
reject(error) // if some error occurs while processing the asynchronous request
});
somePromise.then((response) => {
// some code to execute if the promise is resolved
}).catch((error) => {
// some code to execute if the promise is rejected
});

A promise, in other words, is simply a promise which gets returned either in a resolved or rejected state. You just wrap the supposed asynchronous operation inside a promise object and what the promise invoking code gets is an assurance that the promise will take care of the operation and return either a ‘resolved’(successful) or a ‘rejected’(erroneous) response.

And then, you have the then!! .then() is a promise handler which takes the response out of the promise object and works on it in some manner just as the callback does.

So what do we infer?? A promise is just another way of implementing a callback. Is it or it isn’t?

Hmm, so to clarify on those doubts you would still have, let’s go one step further and look at this conclusive use case.

//callbacks.js code
const asyncAdd = (a, b, callback) => {
setTimeout(() => {
if (typeof(a) != “number” || typeof(b) != “number”) {
callback(undefined, “Must provide a valid input”);
} else {
callback(a + b);
}
}, 2000);
}
const asyncAddOne = (x, callback) => {
setTimeout(() => {
callback(x + 1);
}, 1000);
}
const asyncSquare = (x, callback) => {
setTimeout(() => {
if (typeof(x) != “number”) {
callback(undefined, “Cannot compute square of a non - numeric input”);
} else {
callback(x * x);
}
}, 1000);
}

If you see, the functions defined above in callbacks.js are normal arithmetic functions that have been realigned using the setTimeout method to simulate asynchronous behavior. (For those, who don’t have any clue about setTimeout, it is a function in JavaScript which triggers any method wrapped inside it after a specified time interval). Do make a note that we are doing a type checking on the operands passed in these functions to make sure that only numbers are provided for these arithmetic operations to complete. In case an invalid input is provided like non-integer values, the function will send an error back in its response.

Now, let’s put some code in our app.js file which shall make use of callbacks to process the response emitted by these asynchronous methods in callbacks.js.

//app.js code
//using callbacks
console.log(“Using callbacks”);
callbacks.asyncAdd(2, 4, (resAdd, error) => {
if (error) {
console.log(error);
} else {
console.log(`The result of asyncAdd is ${resAdd}`);
callbacks.asyncAddOne(resAdd, (resAddOne) => {
console.log(`The result of asyncAddOne is ${resAddOne}`);
});
}
});

In real-world JavaScript applications, you’ll come across situations where you might need to use the response of an asynchronous operation (Database/API calls) as an input for some other asynchronous operation waiting in a chain. It’s here that callbacks make a case for themselves. (For example, fetching latitude /longitude details from a geolocation API and, in turn, providing these details as input to a weather API).

We’ll get some glimpse of this happening in our app.js file which has a couple of functions namely ‘asyncAdd’ and ‘asyncAddOne’ chained together. The response we get from the ‘asyncAdd’ function is provided in the callback as an input for the ‘asyncAddOne’ method which simply adds 1 to the input and returns back the computed value. Also, in case the arguments provided at the first place were invalid, there is a check in place inside the callback function which simply logs it to the console. This seems to be a pretty trivial use case.

Take some time to imagine 10–20’s of asynchronous methods chained in procession in app.js after the ‘asyncAddOne’ function. Hard to imagine! Well, 10–20 becomes too small a number sometimes in the world of JavaScript and asynchronous programming. But yes, if we keep using callbacks, we’ll definitely find ourselves in a deeply nested code with every asynchronous call wrapped inside a callback and I am scared to tell as to how readable your code will remain for others to see. Add to that, the need to check errors in the response returned by every asynchronous method and all hell will break loose. Ah indeed, no wonder this phenomenon is referred to as the callback hell in the JavaScript world.

Alright, any healing touch that promises might provide here? Without much ado, let’s jump into the same use case this time making use of promises. For the sake of better separation and code readability, I‘ll move the asynchronous functions (previously in callbacks.js) to a new file called promises.js.

//promises.js
const asyncAdd = (a, b) => {
return new Promise((resolve, reject) => {
setTimeout(() => {
if (typeof(a) != “number” || typeof(b) != “number”) {
//throw new Error(“not a valid input”);
reject(“not a valid input”);
} else {
resolve(a + b);
}
}, 2000);
});
}
const asyncAddOne = (x) => {
return new Promise((resolve, reject) => {
setTimeout(() => {
resolve(x + 1);
}, 1000);
});
}
const asyncSquare = (x) => {
return new Promise((resolve, reject) => {
setTimeout(() => {
if (typeof(x) != “number”) {
reject(“Cannot compute square of a non - numeric input”);
} else {
resolve(x * x);
}
}, 1000);
});
}
module.exports = {
asyncAdd,
asyncAddOne,
asyncSquare
}

So, pretty much the same functions you’ll see here apart from one extra asynchronous function (asyncSquare) which has been put here to better explain how promises deal with the issue of chained asynchronous calls compared to callbacks. As mentioned in the introduction to promises earlier, we make use of resolve and reject to exhibit the status of the asynchronous call back to the caller. If the computation is successful, we send the response wrapped inside a resolved statement else, we send the error in a rejecting statement. Now, let’s have a look at how the promise gets handled as its returned back to the caller method.

//app.js code
// using promises
console.log(“Using ES6 Promises”);
promises.asyncAdd(2, 4).then((resAdd) => {
console.log(`The result of asyncAdd is ${resAdd}`);
return promises.asyncAddOne(resAdd);
}).then((resAddOne) => {
console.log(`The result of asyncAddOne is ${resAddOne}`);
return promises.asyncSquare(4);
}).then((resSquare) => {
console.log(`The result of asyncSquare is ${resSquare}`);
}).catch((error) => {
console.log(error);
});

Hmm, where are those nested lines of code? Ohh, there are none! Exactly!

The .then() handler here is the key.

Note

When the promise is returned back to the handler, we refer to the promise to be in a settled state. While the async operation is in the process, the promise is said to be in a pending state.

So, the then() handler takes the settled promise returned from the first asynchronous call (asyncAdd), checks if the promise is resolved or rejected and based on it, triggers the next asynchronous call or simply propagates the error to the .catch() handler which emits the error and suspends any further asynchronous calls.

Any visible benefits of using promises?- Certainly!

The code looks much readable now with any developer in your team not having to scratch his head to get to know what exactly is happening with the code. Also, only a single catch handler to catch any error thrown at any stage of the chained async operations in place of multiple ‘if’ statements in case of callbacks!

Any questions popping?? — which use cases advocate the usage of promises over callbacks?

Although the bottom line is that both, callbacks and promises, do the same stuff for you, promises will surely come across as a better fit for cases that otherwise demand a deeply nested tree of asynchronous calls with callbacks.

But the choice is totally yours!!

Do keep in mind that promises are simply wrappers around callbacks which are fine-tuned for performances in cases of long nested asynchronous calls.

But yes, when the chain is relatively small (the definition of small??…will keep it open-ended), even callbacks should be good enough to do the job for you.

Summary

I’ll park those thoughts for now and look forward to some interesting ones coming from your side.

Till next time!…