Many elements are involved in the execution of our code and one of those elements is the Web APIs. Operations we can do with the web APIs are: Fetch data, Set local storage, DOM manipulation, etc… These actions are taken apart from the main thread while they are completed. Now the question is, How does our program know when operations have ended? What are we going to do once these operations are finished?
Callbacks represent: What do you want to do once your asynchronous operation is over?
Most asynchronous actions take as an argument another function (callbacks), and once the asynchronous task is finished, the callback function is called.
To see a callback in action lets take as an example setTimeOut, which is an asynchronous function that takes a callback and the time at which it should be executed.
- ‘Hello’ is printed on the console
- Secondly, the setTimeOut function is taken to another thread, and allows the script to continue running. (setTimeOut is a Web API, so it’s placed inside its respective container)
- The last line of code is executed, ‘End’ is printed on the console
- Event loop, check that the call stack is now empty and the callback queue has one callback in line.
- Then move the console.log function to the call stack and now we can see the word ‘world’ printed on the console.
Important to realize that even if we configure our setTimeOut to run in 0 seconds. It’s not going to be executed immediately. The result is going to be the same as before due to the setTimeOut being run in another thread.
The problem comes when you need the result of one function to call the following function. Then you start to nest as many callbacks as you need.
In essence, we are doing more complicated things, detracting from legibility, making the code difficult to maintain. This structure is also known as the Pyramid of Doom, or Callback hell.
Promises: introduced with ECMAScript 6, and brought to the language a more concise way of working with asynchronous functions
One of the most common uses of promises in web development is to control the flow of requests (Ajax) to web servers. Let's take a look at the following snippet.
We have the Fetch method, a web API that returns a promise, and instead of passing async functions we attach them with another method called then(). The result is a more legible and maintainable code, fixing the clutter of nested callbacks and also, making error handling simpler.
If you want to dig deeper on how to actually create a Promise and how to handle errors click on here.
ECMAScript 7 and the arrival of async/await
- First of all, we have the keyword async that it’s placed before the function we want to define as asynchronous
- Optionally, in case you want to check for errors or rejected promises, you can always use try/catch blocks.
Note that, in the end, async await is a syntactic sugar for promises. The code looks sequential, in a synchronous way but it’s still a promise-based asynchronous code. It is also mentioned that this method enables some interesting optimizations of Memory and performance too in JS Engine.
Top comments (1)
So, I am a senior full stack developer and I think we can collaborate each other in many side of development.