JavaScript: Promises and Why Async/Await Wins the Battle

The ease and benefits of Async/Await

Nick Parsons
Jul 26, 2018 · 5 min read

Asynchronous functions are a good and bad thing in JavaScript. The good side is that asynchronous functions are non-blocking and, therefore, are fast — especially in a Node.js context. The downside is that dealing with asynchronous functions can be cumbersome, as you sometimes have to wait for one function to complete in order to get its “callback” before proceeding to the next execution.

There are a handful of ways to play to the strengths of asynchronous function calls and properly handle their execution, but one is far superior to the rest (spoiler: it’s Async/Await). In this quick read, you’ll learn about the ins and outs of Promises and the use of Async/Await, as well as our opinion on how the two compare.


Promises vs. Callbacks

As a JavaScript or Node.js developer, properly understanding the difference between Promises and Callbacks and how they work together is crucial.

There are small but important differences between the two. At the core of every Promise, there is a callback resolving some kind of data (or error) that bubbles up to the Promise being invoked.

The callback handler:

Calling the validatePassword() function:

The code snippet below shows a full end to end check for validating a password (it’s static and must match “bambi,” my favorite cartoon character as a child):

The code is commented pretty well. However, if you’re confused, the catch only executes in the event that a reject() is called from the Promise. Since the passwords don’t match, we call reject(), therefore “catching” the error and sending it to the done() function.


Promises provide a simpler alternative for executing, composing, and managing asynchronous operations when compared to traditional callback-based approaches. They also allow you to handle asynchronous errors using approaches that are similar to synchronous try/catch.

Promises also provide three unique states:

  1. Pending — the Promise’s outcome hasn’t yet been determined because the asynchronous operation that will produce its result hasn’t completed yet.

When a Promise is pending, it can transition to the fulfilled or rejected state. Once a Promise is fulfilled or rejected, however, it will never transition to any other state, and its value or failure reason will not change.

The Downside

The one thing Promises don’t do is solve what is called “callback hell,” which is really just a series of nested function calls. Sure, for one call it’s OK. For many calls, your code becomes difficult, if not impossible, to read and maintain.

Looping in Promises

To avoid deeply nested callbacks with JavaScript, one would assume that you could simply loop over the Promises, returning the results to an object or array, and it will stop when it’s done. Unfortunately, it’s not that easy; due to the asynchronous nature of JavaScript, there’s no “done” event that is called when your code is complete if you’re looping through each Promise.

The correct way to approach this type of situation is to use Promise.all(). This function waits for all fulfillments (or the first rejection) before it is marked as finished.

Error Handling

Error handling with multiple nested Promise calls is like driving a car blindfolded. Good luck finding out which Promise threw the error. Your best bet is to remove the catch() method altogether and opt in for a global error handler (and cross your fingers) like so:



Note: The above two options are the only two ways to ensure that you’re catching errors. If you miss adding a catch() method, it’ll be swallowed up by the code.


Async/Await allows us to write asynchronous JavaScript that looks synchronous. In previous parts of this post, you were introduced to Promises that were supposed to simplify asynchronous flow and avoid callback hell but they didn’t.

Callback Hell?

Callback hell is a term used to describe the following scenario:

Note: As an example, here’s an API call that would get four specific users from an array.

Whew, that’s ugly and takes up a TON of space in the code.

Async/Await is the latest and greatest thing to come to JavaScript, allowing us to not only avoid callback hell but ensure that our code is clean and that errors are properly captured. What I find most fascinating about Async/Await is that it is built on top of Promises (non-blocking, etc.), yet allows for code to be readable and reads as if it were synchronous. This is where the power lies.

Note: Here’s an example of the same set of API calls to retrieve four users from an array, in more than half the lines of code:

Fancy, right?

And because Async/Await is built on top of Promises, you can even use Promise.all() with the await keyword:

Note: Async/Await is slightly slower due to its synchronous nature. You should be careful when using it multiple times in a row as the Await keyword stops the execution of all the code after it — exactly as it would be in synchronous code.

How Do I Start Using Async/Await?

Working with Async/Await is surprisingly easy to understand and use. In fact, it’s available natively in the latest version of Node.js and is quickly making its way to browsers. For now, if you want to use it client-side, you’ll need to use Babel, an easy-to-use and setup transpiler for the web.


Let’s start with the Async keyword. It can be placed before function, like this:


The keyword Await makes JavaScript wait until that Promise settles and returns its result. Here’s an example:

Full Example:

Why Is Async/Await Better?

Now that we’ve gone over a lot of what Promises and Async/Await have to offer, let’s recap why we (Stream) feel that Async/Await is a superior choice for our code base.

  1. Async/Await allows for a clean and concise code base with fewer lines of code, less typing, and fewer errors. Ultimately, it makes complicated, nested code readable again.

Final Thoughts

I can say that Async/Await is one of the most powerful features that has been added to JavaScript in the past few years.

It took less than one day to understand the syntax and see what a mess our code base was in that regard. It took about two days total to convert all of our Promise-based code to Async/Await, essentially a complete rewrite — which just goes to show how little code is required when using Async/Await.

Lastly, thank you for reading this piece. If you enjoyed it, please give me a clap (or 50 if you’re feeling extra nice). Thank you!

Happy coding!

Better Programming

Advice for programmers.

Nick Parsons

Written by

Technical Writer🖋 Coder 👨‍💻 Outdoor Enthusiast 🏔️ Wannabe Astronaut 👨‍🚀 🔗

Better Programming

Advice for programmers.

More From Medium

More from Better Programming

More from Better Programming

More from Better Programming

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade