One of the keys to writing a successful web application is being able to make dozens of AJAX calls per page.

This is a typical asynchronous programming challenge, and how you choose to deal with asynchronous calls will, in large part, make or break your app, and by extension potentially your entire startup.

Synchronizing asynchronous tasks in JavaScript was a serious issue for a very long time.

This challenge is affecting back-end developers using Node.js as much as front-end developers using any JavaScript framework. Asynchronous programming is a part of our everyday work, but the challenge is often taken lightly and not considered at the right time.

A Brief History of Asychronous JavaScript

The first and the most straightforward solution came in the form of nested functions as callbacks. This solution led to something called callback hell, and too many applications still feel the burn of it.

Then, we got Promises. This pattern made the code a lot easier to read, but it was a far cry from the Don’t Repeat Yourself (DRY) principle. There were still too many cases where you had to repeat the same pieces of code to properly manage the application’s flow. The latest addition, in the form of async/await statements, finally made asynchronous code in JavaScript as easy to read and write as any other piece of code.

Let’s take a look at the examples of each of these solutions and reflect on the evolution of asynchronous programming in JavaScript.

To do this, we will examine a simple task that performs the following steps:

  1. Verify the username and password of a user.
  2. Get application roles for the user.
  3. Log application access time for the user.

Approach 1: Callback Hell (“The Pyramid of Doom”)

The ancient solution to synchronize these calls was via nested callbacks. This was a decent approach for simple asynchronous JavaScript tasks, but wouldn’t scale because of an issue called callback hell.

Illustration: Asynchronous JavaScript callback hell anti-pattern

The code for the three simple tasks would look something like this:

const verifyUser = function(username, password, callback){
   dataBase.verifyUser(username, password, (error, userInfo) => {
       if (error) {
           callback(error)
       }else{
           dataBase.getRoles(username, (error, roles) => {
               if (error){
                   callback(error)
               }else {
                   dataBase.logAccess(username, (error) => {
                       if (error){
                           callback(error);
                       }else{
                           callback(null, userInfo, roles);
                       }
                   })
               }
           })
       }
   })
};

Each function gets an argument which is another function that is called with a parameter that is the response of the previous action.

Too many people will experience brain freeze just by reading the sentence above. Having an application with hundreds of similar code blocks will cause even more trouble to the person maintaining the code, even if they wrote it themselves.

This example gets even more complicated once you realize that a database.getRoles is another function that has nested callbacks.

const getRoles = function (username, callback){
   database.connect((connection) => {
       connection.query('get roles sql', (result) => {
           callback(null, result);
       })
   });
};

In addition to having code that is difficult to maintain, the DRY principle has absolutely no value in this case. Error handling, for example, is repeated in each function and the main callback is called from each nested function.

More complex asynchronous JavaScript operations, such as looping through asynchronous calls, is an even bigger challenge. In fact, there is no trivial way of doing this with callbacks. This is why JavaScript Promise libraries like Bluebird and Q got so much traction. They provide a way to perform common operations on asynchronous requests that the language itself doesn’t already provide.

That’s where native JavaScript Promises come in.

JavaScript Promises

Promises were the next logical step in escaping callback hell. This method did not remove the use of callbacks, but it made the chaining of functions straightforward and simplified the code, making it much easier to read.

Illustration: Asynchronous JavaScript Promises diagram

With Promises in place, the code in our asynchronous JavaScript example would look something like this:

const verifyUser = function(username, password) {
   database.verifyUser(username, password)
       .then(userInfo => dataBase.getRoles(userInfo))
       .then(rolesInfo => dataBase.logAccess(rolesInfo))
       .then(finalResult => {
           //do whatever the 'callback' would do
       })
       .catch((err) => {
           //do whatever the error handler needs
       });
};

To achieve this kind of simplicity, all of the functions used in the example would have to be Promisified. Let’s take a look at how the getRoles method would be updated to return a Promise:

const getRoles = function (username){
   return new Promise((resolve, reject) => {
       database.connect((connection) => {
           connection.query('get roles sql', (result) => {
               resolve(result);
           })
       });
   });
};

We have modified the method to return a Promise, with two callbacks, and the Promise itself performs actions from the method. Now, resolve and reject callbacks will be mapped to Promise.then and Promise.catch methods respectively.

You may notice that the getRoles method is still internally prone to the pyramid of doom phenomenon. This is due to the way database methods are created as they do not return Promise. If our database access methods also returned Promise the getRoles method would look like the following:

const getRoles = new function (userInfo) {
   return new Promise((resolve, reject) => {
       database.connect()
           .then((connection) => connection.query('get roles sql'))
           .then((result) => resolve(result))
           .catch(reject)
   });
};

Approach 3: Async/Await

JavaScript is asynchronous by default. This might be reason why it took so long to get synchronous-looking code that runs properly in JavaScript. But, better late than never! The pyramid of doom was significantly mitigated with the introduction of Promises. However, we still had to rely on callbacks that are passed on to .then and .catch methods of a Promise.

Promises paved the way to one of the coolest improvements in JavaScript. ECMAScript 2017 brought in syntactic sugar on top of Promises in JavaScript in the form of async and await statements.

They allow us to write Promise-based code as if it were synchronous, but without blocking the main thread, as this code sample demostrates:

const verifyUser = async function(username, password){
   try {
       const userInfo = await dataBase.verifyUser(username, password);
       const rolesInfo = await dataBase.getRoles(userInfo);
       const logStatus = await dataBase.logAccess(userInfo);
       return userInfo;
   }catch (e){
       //handle errors as needed
   }
};

Awaiting Promise to resolve is allowed only within async functions which means that verifyUser had to be defined using async function.

However, once this small change is made you can await any Promise without additional changes in other methods.

Async - A Long Awaited Resolution of a Promise

Async functions are the next logical step in the evolution of asynchronous programming in JavaScript. They will make your code much cleaner and easier to maintain. Declaring a function as async will ensure that it always returns a Promise so you don’t have to worry about that anymore.

Why should you start using the JavaScript async function today?

  1. The resulting code is much cleaner.
  2. Error handling is much simpler and it relies on try/catch just like in any other synchronous code.
  3. Debugging is much simpler. Setting a breakpoint inside a .then block will not move to the next .then because it only steps through synchronous code. But, you can step through await calls as if they were synchronous calls.

Understanding the Basics

What are async and await?

Async/await statements are syntactic sugar created on top of JavaScript Promises. They allow us to write Promise-based code as if it were synchronous, but without blocking the main thread.

About the author

Demir Selmanovic, Bosnia and Herzegovina
member since May 23, 2014
Demir is a developer and project manager with over 15 years of professional experience in a wide range of software development roles. He excels as a solo developer, team member, team leader, or manager of multiple distributed teams. He works closely with clients to define ideas and deliver products. [click to continue...]
Hiring? Meet the Top 10 Freelance JavaScript Developers for Hire in July 2018

Comments

Peter Edache
Nice insight.
Randy Casburn
Nice brief. May I recommend that you consider changing your WrapUp header? This "Wrapping Up: Async/Await vs. Promises" sounds as if the two ideas are competing while in fact they are complimentary. Would not want a novice to be confused. You have nailed to idea home though - Async/Await is a great enhancement to Promises.
Joachim
Just a quick note, your second example with promise-returning database methods can be simplified to: const getRoles = new function (userInfo) { return database.connect() .then((connection) => connection.query('get roles sql')); }; In general, code inside a new Promise() that simply passes resolve and reject to an inner Promise is always a superfluous wrapper.
The Master
I don't think Demir Selmanovic gives a ..block about your quick note !
Demir Selmanovic
Hey, thanks for the tip. Yeah, I'm aware that the code could have been made more concise. But the purpose of the post and the samples is to illustrate differences and progress from callback hell onward to the people that are not yet sure about "what the hell are Promisses". So I chose to use the "more obvious" solution.
Demir Selmanovic
Well, I actually gave a paragraph :)
Joachim
Fair enough. In that case, I think the call to forward to resolve should either be .then(resolve) or .then(result => resolve(result)) depending on what you think is clearer.
Eduardo Campver
Hi there, just something I consider worth adding: the use of generator functions and promises together. It lays right between Promises and async/await. There is this package called `co-router` which allows you to use generator functions as route handlers in Express, then wherever a Promise was returned you could just use `yield asyncCall(args)`, sort of like `await`, but not quite though. Oh and thanks for the great post ;)
Demir Selmanovic
Agreed. Better now? :)
Demir Selmanovic
Hi Randy, thanks for the tip. We have updated the header to something more interesting. I believe it is better now.
Demir Selmanovic
You are welcome, glad you liked the post :) I had my doubts about adding generators. I decided to keep them out because I personally don't think they will gain that much traction comparing to what Promises gave us. And now that async/await is available (pretty much) I expect that many people will not even get into Generators. Still, I might be wrong so thanks for pointing it here so the readers will at least hear about them.
Joachim
Yes, that's what I meant…
The Master
Yes @demirselmanovic:disqus , you did ! https://uploads.disquscdn.com/images/45fdda64764a2898995bc4cb72a69874914dbfd9342188d4d49913e6af86ff1f.jpg
Eduardo Campver
I definitely wouldn't recommend using generators over async/await, it was just a bit of syntactic sugar back then before the "better syntactic sugar" came into play. As soon as I was able to, I replaced all use of `function*` and `yield` for `async function` and `await` respectively.
Randy Casburn
https://uploads.disquscdn.com/images/f2b6df6b9652d037680d63475843088e53ad2d483511d481ac240c5b0cc75a8a.png
Eki Eqbal
Next time someone asks me about the differences between Async/Await and JS Promises I am pointing them here. You did a very nice job in your write up, keep it up and thanks again for sharing. As a side note, @demirselmanovic:disqus has already written a book about ES9, It’s currently sealed up. In two years, the JS community is going to open the book to see if the language design team got it right. Cheers
Demir Selmanovic
Thanks Eki !!! :)
Leonard Lepadatu
The idea of this kind of article is not new. Gil Tayar made this three years ago in hebrew, then in english. Please fell free to watch: https://youtu.be/OPqK93zFdAg https://youtu.be/DHRZbkQ8KMw https://youtu.be/AAsh8NFzQaU
iweczek
Under Approach 3, I think you meant to say "JavaScript is synchronous by default." and "why it took so long to get asynchronous-looking code"...
Esteban
Excelent job
Nick McCrea
Great article Demir! Just what I was looking for!
Semyon Zadorozhniy
Thanks
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Demir Selmanovic
JavaScript Developer
Demir is a developer and project manager with over 15 years of professional experience in a wide range of software development roles. He excels as a solo developer, team member, team leader, or manager of multiple distributed teams. He works closely with clients to define ideas and deliver products.