JavaScript Promises. Part 1 — Why Promises ?
If you want to be proficient in JavaScript, it is imperative to learn Asynchronous JS. One of the first words that you will hear in Asynchronous JS is Promises.
It is not possible to explain all of the key concepts in a single article. So this will be a 4 part series that helps you lay the foundation of the major concepts in Promises.
This article will explain why Promises were introduced and what it offers to the world of Asynchronous JS. If you are already familiar with the “why” or want to go directly into the basics, click here to go to the second part of the series.
So let's get started.
Asynchronous JavaScript
What would be the output of the below code?
1 2 3 or something else?
setTimeout with 0-millisecond delay is invoked, there won’t be any delay. So 2 should be printed next right?
The actual output is 1 3 2.
Why?
That’s how Asynchronous JS Works. When the JavaScript Engine encounters a function that is to be executed not right away, but at some point in the future, instead of waiting/blocking the thread at that point, it will queue that function. And when it is time to execute the function, JS Engine will take it out of the queue and execute it.
So, setTimeout will be queued irrespective of its delay and the rest of the code will be executed. And once the wait time is over, the function inside setTimeout will be taken up from the queue and executed.
I’m not going to go into details. That is a topic for another day. But I hope the basic idea is clear. Now, what has this got to do anything with promises you may ask. This is the basis of Asynchronous JS and you have to understand it in order to understand the next topic
Callbacks and Callback Hell
A callback function is a function passed into another function as an argument and will be executed inside it.
The arrow function with a simple console.log that was passed into the setTimeout function in our previous example is in fact a callback. After a specified amount of wait time, the callback (arrow function) was executed.
So what is callback hell?
Suppose we have a function that loads a script from the server.
loadScript(fileName, callBack);
fileName is the name of the file to be loaded. And callBack is the function that will be executed (called back) once the file is loaded or if an error occurs.
After the 1st file is loaded, if there is no error, we need to load the second script file. The code would look like this
You would feel some unease seeing this. If not, suppose we have to load 10 or 15 files, the functions will be nested and nested and it would resemble what is called a “pyramid of doom”. And the code that is to be executed after all those files will be under all that nested code and it is not only hard to maintain but also very difficult to understand/read the code. This is termed “Callback Hell”.
From these examples, it can be understood that a better approach is required to handle asynchronous codes.
Enter Promises
Now that we have understood the “Why”, let’s learn the “How”. Click here to go to the next part, which explains that.
If you have found this article helpful, make sure to clap and share it with your friends. Make sure to follow me for more simplified explanations.
