For those who have never heard of this topic before, here’s a quick intro <ul><li>Async/await is a new way to write asynchronous code. Previous alternatives for asynchronous code are callbacks and promises. </li><li>Async/await is actually just syntax sugar built on top of promises. It cannot be used with plain callbacks or node callbacks. </li><li>Async/await is, like promises, nonblocking. </li><li>Async/await makes asynchronous code look and behave a little more like synchronous code. This is where all its power lies. </li></ul>

Async/Await 101

<img alt="Mostafa Gaafar" src="https://miro.medium.com/max/500/1*Hr5GBD49EH_DD5VTJ0BZ8Q" width="48" height="48">👉 This article has been updated and republished, <a href="https://dev.to/gafi/7-reasons-to-always-use-async-await-over-plain-promises-tutorial-4ej9" rel="noopener" dir="ltr">read the latest version here</a>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.<h1 data-selectable-paragraph="">Async/Await 101</h1>For those who have never heard of this topic before, here’s a quick intro<UL><LI>Async/await is a new way to write asynchronous code. Previous alternatives for asynchronous code are callbacks and promises.</LI><LI>Async/await is actually just syntax sugar built on top of promises. It cannot be used with plain callbacks or node callbacks.</LI><LI>Async/await is, like promises, non blocking.</LI><LI>Async/await makes asynchronous code look and behave a little more like synchronous code. This is where all its power lies.</LI></UL><h1 data-selectable-paragraph="">Syntax</h1>Assuming a function <code dir="ltr">getJSON</code> that returns a promise, and that promise resolves with some JSON object. We just want to call it and log that JSON, then return <code dir="ltr">"done"</code>.This is how you would implement it using promisesAnd this is how it looks with async/awaitThere are a few differences here<OL><LI>Our function has the keyword <code dir="ltr">async</code> before it. The <code dir="ltr">await</code> keyword can only be used inside functions defined with <code dir="ltr">async</code>. Any <code dir="ltr">async</code> function returns a promise implicitly, and the resolve value of the promise will be whatever you <code dir="ltr">return</code> from the function (which is the string <code dir="ltr">"done"</code> in our case).</LI><LI>The above point implies that we can’t use await in the top level of our code since that is not inside an <code dir="ltr">async</code> function.</LI></OL>3. <code dir="ltr">await getJSON()</code> means that the <code dir="ltr">console.log</code> call will wait until <code dir="ltr">getJSON()</code> promise resolves and print it value.<h1 data-selectable-paragraph="">Why Is It better?</h1><h2 data-selectable-paragraph="">1. Concise and clean</h2>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 <code dir="ltr">.then</code>, create an anonymous function to handle the response, or give a name <code dir="ltr">data</code> to a variable that we don’t need to use. We also avoided nesting our code. These small advantages add up quickly, which will become more obvious in the following code examples.<h2 data-selectable-paragraph="">2. Error handling</h2>Async/await makes it finally possible to handle both synchronous and asynchronous errors with the same construct, good old <code dir="ltr">try/catch</code>. In the example below with promises, the <code dir="ltr">try/catch</code> will not handle if <code dir="ltr">JSON.parse</code> fails because it’s happening inside a promise. We need to call <code dir="ltr">.catch</code> on the promise and duplicate our error handling code, which will (hopefully) be more sophisticated than <code dir="ltr">console.log</code> in your production ready code.Now look at the same code with async/await. The <code dir="ltr">catch</code> block now will handle parsing errors.<h2 data-selectable-paragraph="">3. Conditionals</h2>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.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.<h2 data-selectable-paragraph="">4. Intermediate values</h2>You have probably found yourself in a situation where you call a <code dir="ltr">promise1</code> and then use what it returns to call <code dir="ltr">promise2</code>, then use the results of both promises to call a <code dir="ltr">promise3</code>. Your code most likely looked like thisIf <code dir="ltr">promise3</code> didn’t require <code dir="ltr">value1</code> it would be easy to flatten the promise nesting a bit. If you are the kind of person who couldn’t live with this, you could wrap both values 1 &amp; 2 in a <code dir="ltr">Promise.all</code> and avoid deeper nesting, like thisThis approach sacrifices semantics for the sake of readability. There is no reason for <code dir="ltr">value1</code> &amp; <code dir="ltr">value2</code> to belong in an array together, except to avoid nesting promises.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.<h2 data-selectable-paragraph="">5. Error stacks</h2>Imagine a piece of code that calls multiple promises in a chain, and somewhere down the chain an error is thrown.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 <code dir="ltr">callAPromise</code> which is totally innocent of this error (the file and line number are still useful though).However, the error stack from async/await points to the function that contains the errorThis 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 <code dir="ltr">makeRequest</code> is better than knowing that the error came from a <code dir="ltr">then</code> after a <code dir="ltr">then</code> after a <code dir="ltr">then</code> …<h2 data-selectable-paragraph="">6. Debugging</h2>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<OL><LI>You can’t set breakpoints in arrow functions that return expressions (no body).</LI></OL><figure><img alt="" src="https://miro.medium.com/max/500/1*n_V4LaVdBOFgGCbmTR_VKA.png" width="680" height="241"><figcaption dir="auto">Try setting a breakpoint anywhere here</figcaption></figure>2. If you set a breakpoint inside a <code dir="ltr">.then</code> block and use debug shortcuts like step-over, the debugger will not move to the the following <code dir="ltr">.then</code> because it only “steps” through synchronous code.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.<figure><img alt="" src="https://miro.medium.com/max/500/1*GWYd4eLrs0U96MkNNVB56A.png" width="680" height="232"></figure><h1 data-selectable-paragraph="">In Conclusion</h1>Async/await is one of the most revolutionary features that have been added to <a href="https://hackernoon.com/tagged/JavaScript" rel="noopener" dir="ltr">JavaScript</a> in the past few years. It makes you realize what a syntactical mess promises are, and provides an intuitive replacement.<h1 data-selectable-paragraph="">Concerns</h1>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 <code dir="ltr">.then</code>, 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 <a href="https://twitter.com/imGaafar" rel="noopener" dir="ltr">@imgaafar</a><figure><img alt="" src="https://miro.medium.com/max/500/1*35tCjoPcvq6LbB3I6Wegqw" width="785" height="94"></figure>

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…

computerscience

Computer Science

artificialintelligence

Artificial Intelligence

👉 This article has been updated and republished, <a href="https://dev.to/gafi/7-reasons-to-always-use-async-await-over-plain-promises-tutorial-4ej9">read the latest version here </a>

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.

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

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

Assuming a function <code>getJSON </code>that returns a promise, and that promise resolves with some JSON object. We just want to call it and log that JSON, then return <code>"done" </code>.

This is how you would implement it using promises

And this is how it looks with async/await

<ol><li>Our function has the keyword <code>async </code>before it. The <code>await </code>keyword can only be used inside functions defined with <code>async </code>. Any <code>async </code> function returns a promise implicitly, and the resolve value of the promise will be whatever you <code>return </code> from the function (which is the string <code>"done" </code> in our case). </li><li>The above point implies that we can’t use await in the top level of our code since that is not inside an <code>async </code>function. </li> </ol>

3. <code>await getJSON() </code>means that the <code>console.log </code>call will wait until <code>getJSON() </code>promise resolves and print it value.

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 <code>.then </code>, create an anonymous function to handle the response, or give a name <code>data </code>to a variable that we don’t need to use. We also avoided nesting our code. These small advantages add up quickly, which will become more obvious in the following code examples.

Async/await makes it finally possible to handle both synchronous and asynchronous errors with the same construct, good old <code>try/catch </code>. In the example below with promises, the <code>try/catch </code>will not handle if <code>JSON.parse </code>fails because it’s happening inside a promise. We need to call <code>.catch </code>on the promise and duplicate our error handling code, which will (hopefully) be more sophisticated than <code>console.log </code>in your production ready code.

Now look at the same code with async/await. The <code>catch </code>block now will handle parsing errors.

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.

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.

You have probably found yourself in a situation where you call a <code>promise1 </code>and then use what it returns to call <code>promise2 </code>, then use the results of both promises to call a <code>promise3 </code>. Your code most likely looked like this

If <code>promise3 </code>didn’t require <code>value1 </code>it would be easy to flatten the promise nesting a bit. If you are the kind of person who couldn’t live with this, you could wrap both values 1 & 2 in a <code>Promise.all </code>and avoid deeper nesting, like this

This approach sacrifices semantics for the sake of readability. There is no reason for <code>value1 </code>& <code>value2 </code>to belong in an array together, except to avoid nesting promises.

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.

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

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 <code>callAPromise </code>which is totally innocent of this error (the file and line number are still useful though).

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

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 <code>makeRequest </code>is better than knowing that the error came from a <code>then </code>after a <code>then </code>after a <code>then </code>…

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

<ol><li>You can’t set breakpoints in arrow functions that return expressions (no body). </li> </ol>

2. If you set a breakpoint inside a <code>.then </code>block and use debug shortcuts like step-over, the debugger will not move to the the following <code>.then </code>because it only “steps” through synchronous code.

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.

Async/await is one of the most revolutionary features that have been added to <a href="https://hackernoon.com/tagged/JavaScript">JavaScript </a>in the past few years. It makes you realize what a syntactical mess promises are, and provides an intuitive replacement.

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 <code>.then </code>, 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 <a href="https://twitter.com/imGaafar">@imgaafar </a>

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

Async/Await 101

Jeffrey Rich's ideas are part of this journey:

Related collections

Similar ideas