See, I don't usually assume, but here I am assuming that you have some understanding of callback and async JS. If not, do not panic, please visit my previous blog Async JS in a nutshell - Basics. It was all clear that this entire concept was about the workflow and this understanding of "Start now and finish it nicely later". That was not it, I also gave a real-life example of the Amazon blah blah. But that's not it.

Sometimes, some things happen one after the other.

Yes, it is the need of the hour at least when it comes to JS. "What are you even talking about?". Yes, I did say JS can skip lines while code is being executed and now I am saying there are things that should happen one after the other. Take it with a pinch of salt, and take it this way.

Examples:

1. You order the food, and only then is the food on the table.
2. You can go to the payment page on Amazon only if you have ordered something or have something in your cart/basket.
3. You can make a tweet only if you log in, and so many examples.

Step 2 happens only after step -1. You make a request to the server, and only then there is a response.

Similarly, callbacks can occur after the callback, the first set of data comes in, and only then the second set of data is needed. CallBack after a callBack. A simple example and then a complex one. Okay? In this, callback after the callback is executed. Look at the below example. I will tell you in a while.

What happened here?

Understand two things discussed,

1. CallBack is something that starts now and finishes sometime later.
2. Some things happen or occur one after the other.

Explanation: Note: 2 seconds is 2000 milliseconds

• Line number 1, setTimeout is fired, its callback is executed after 2000 ms and line number 9 indicates that clearly. It prints what it had to print.
• Immediately line 3 has a setTimeout, it fires, the callback is executed after 2000 ms of its own setTimeout so outer 2 seconds and inner 2 seconds (4 seconds) of wait, and theconsole.log("I am the second callback after 2 + 2 seconds");
• And you guessed it right line 5 setTimeout is fired, **the time wait is again 2000 ms, so the callback happens after 2000ms of its inner setTimeout delay. So, the parent had 2 seconds, the child had 2 seconds so the inner child or the setTimeout takes 2000 + 2000 + 2000 = 6000 ms or 6 seconds.

VERY IMPORTANT TO UNDERSTAND THE ABOVE

Concern - The Triangular Doom

The triangular arc in the image is a pain. See that, why just imagine if it goes on and on and on? The readability is buried and it's a mess. Trust me.

Imagine on a higher scale. The entire purpose of the callback is just a set of unwanted pieces of code that nobody can understand.

Now, I am telling you that this is the story of a setTimeout but what if it is a data fetching or a simple file read? It is quite tedious. Now, what is this data fetching? Data that comes from a database or an external data resource such as a third-party API.

If on any day an e-commerce site tries to getSomeData, or a bank server is trying to getSomeData and the scenario is one step at a time or one data fetch at a time. It is a nightmare and a clear mess. Check this.

Leaving you with I, you, and Amazon too cannot use CALLBACK and get into callback hell and there are other suitable ways to deal with this. That is Promises, the async/ await which is for our next meal.

Thanks a ton for reading this and I hope you got an overview. See you soon.