6 Reasons Why JavaScript Async/Await Blows Promises Away (Tutorial)

March 16th 2017 435,430 reads

@mgaafarMostafa Gaafar

Software Engineer @ Amazon London. Likes scalable distributed stuff & JavaScript

👉 This article has been updated and republished, read the latest version here

NodeJS supports async/await out of the box since version 7.6. I believe it has been the single greatest addition to JS since 2017. If you haven’t tried it yet, here are a bunch of reasons with examples why you should adopt it immediately and never look back.

Async/Await 101

For those who have never heard of this topic before, here’s a quick intro

Async/await is a new way to write asynchronous code. Previous alternatives for asynchronous code are callbacks and promises.Async/await is actually just syntax sugar built on top of promises. It cannot be used with plain callbacks or node callbacks.Async/await is, like promises, non blocking.Async/await makes asynchronous code look and behave a little more like synchronous code. This is where all its power lies.

Syntax

Assuming a function

getJSON

"done".

This is how you would implement it using promises

const makeRequest = () =>
  getJSON()
    .then(data => {
      console.log(data)
      return "done"
    })

makeRequest()

And this is how it looks with async/await:

const makeRequest = async () => {
  console.log(await getJSON())
  return "done"
}

makeRequest()

There are a few differences here:

1. Our function has the keyword

async

await

async

2. The above point implies that we can’t use await in the top level of our code since that is not inside an async function.

// this will not work in top level
// await makeRequest()

// this will work
makeRequest().then((result) => {
  // do something
})

3.

await getJSON()

getJSON() 

Why Is It better?

1. Concise and clean

Look at how much code we didn’t write! Even in the contrived example above, it’s clear we saved a decent amount of code. We didn’t have to write 

.then

data

2. Error handling

Async/await makes it finally possible to handle both synchronous and asynchronous errors with the same construct, good old

try/catch

try/catch

JSON.parse

.catch

console.log

const makeRequest = () => {
  try {
    getJSON()
      .then(result => {
        // this parse may fail
        const data = JSON.parse(result)
        console.log(data)
      })
      // uncomment this block to handle asynchronous errors
      // .catch((err) => {
      //   console.log(err)
      // })
  } catch (err) {
    console.log(err)
  }

Now look at the same code with async/await. The

catch

const makeRequest = async () => {
  try {
    // this parse may fail
    const data = JSON.parse(await getJSON())
    console.log(data)
  } catch (err) {
    console.log(err)
  }
}

3. Conditionals

Imagine something like the code below which fetches some data and decides whether it should return that or get more details based on some value in the data.

const makeRequest = () => {
  return getJSON()
    .then(data => {
      if (data.needsAnotherRequest) {
        return makeAnotherRequest(data)
          .then(moreData => {
            console.log(moreData)
            return moreData
          })
      } else {
        console.log(data)
        return data
      }
    })
}

Just looking at this gives you a headache. It’s easy to get lost in all that nesting (6 levels), braces, and return statements that are only needed to propagate the final result up to the main promise.

This example becomes way more readable when rewritten with async/await.

const makeRequest = async () => {
  const data = await getJSON()
  if (data.needsAnotherRequest) {
    const moreData = await makeAnotherRequest(data);
    console.log(moreData)
    return moreData
  } else {
    console.log(data)
    return data    
  }
}

4. Intermediate values

You have probably found yourself in a situation where you call a

promise1

promise2

promise3

const makeRequest = () => {
  return promise1()
    .then(value1 => {
      // do something
      return promise2(value1)
        .then(value2 => {
          // do something          
          return promise3(value1, value2)
        })
    })
}

If

promise3

Promise.all

const makeRequest = () => {
  return promise1()
    .then(value1 => {
      // do something
      return Promise.all([value1, promise2(value1)])
    })
    .then(([value1, value2]) => {
      // do something          
      return promise3(value1, value2)
    })
}

This approach sacrifices semantics for the sake of readability. There is no reason for

value1

value2

This same logic becomes ridiculously simple and intuitive with async/await. It makes you wonder about all the things you could have done in the time that you spent struggling to make promises look less hideous.

const makeRequest = async () => {
  const value1 = await promise1()
  const value2 = await promise2(value1)
  return promise3(value1, value2)
}

5. Error stacks

Imagine a piece of code that calls multiple promises in a chain, and somewhere down the chain an error is thrown.

const makeRequest = () => {
  return callAPromise()
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => {
      throw new Error("oops");
    })
}

makeRequest()
  .catch(err => {
    console.log(err);
    // output
    // Error: oops at callAPromise.then.then.then.then.then (index.js:8:13)

The error stack returned from a promise chain gives no clue of where the error happened. Even worse, it’s misleading; the only function name it contains is

callAPromise

However, the error stack from async/await points to the function that contains the error

const makeRequest = async () => {
  await callAPromise()
  await callAPromise()
  await callAPromise()
  await callAPromise()
  await callAPromise()
  throw new Error("oops");
}

makeRequest()
  .catch(err => {
    console.log(err);
    // output
    // Error: oops at makeRequest (index.js:7:9)
  })

This is not a huge plus when you’re developing on your local environment and have the file open in an editor, but it’s quite useful when you’re trying to make sense of error logs coming from your production server. In such cases, knowing the error happened in

makeRequest

6. Debugging

Last but not least, a killer advantage when using async/await is that it’s much easier to debug. Debugging promises has always been such a pain for 2 reasons

1. You can’t set breakpoints in arrow functions that return expressions (no body).

Try setting a breakpoint anywhere here

2. If you set a breakpoint inside a 

.then

 .then

With async/await you don’t need arrow functions as much, and you can step through await calls exactly as if they were normal synchronous calls.

In Conclusion

Async/await is one of the most revolutionary features that have been added to JavaScript in the past few years. It makes you realize what a syntactical mess promises are, and provides an intuitive replacement.

Concerns

Some valid skepticism you might have about using this feature is that it makes asynchronous code less obvious: Our eyes learned to spot asynchronous code whenever we see a callback or a .then, it will take a few weeks for your eyes to adjust to the new signs, but C# had this feature for years and people who are familiar with it know it’s worth this minor, temporary inconvenience.

Follow me on twitter @imgaafar

Related

Learn in-demand skills & level up your career with Udacity!

Visit Udacity https://bit.ly/3n8mJd4

promoted

Everything You Need to Know About Multithreading: Sequential Consis...

pre-emoji story

#programming

@xylophoonBi-Gee

10/19/20

Introducing FBSQL: Frontend Backend SQL Server

pre-emoji story

#frontend-backend

@fbsqlFBSQL

10/18/20

Subscribe to get your daily round-up of top tech stories!