Wait For It…

Define Async/Await in JavaScript in One Sentence

The async/await pattern allows non-blocking code to be written as though it’s blocking code.


Languages without multi-threading may wish to run things in the background. One way to do that is via callbacks. The best example is the classic setTimeout callback in the browser:

setTimeout(function(){ alert("Hello"); }, 3000);

Here we offer a callback – the anonymous function – to something which will, in the background, do its own thing (waiting for a timeout in this case) and then, when there’s available CPU for processing it, execute our callback.

The problem with using callbacks is that it’s quite a backwards way of programming. We have to construct the callback at the point of invoking the background job, and then our main activity either goes onto something else, or then ends.

If there are a chain of activities to perform, then the callback we pass must manage that chain, and it’s not very easy to read such code.

Promise You’ll Do Better

Enter Promise – the JavaScript wrapper for callbacks.

A Promise wraps some activity that will eventually complete. It may have already completed it. Promises can be composed with additional follow on behaviour via .then. If there’s an error running a promise, then the .catch behaviour can be used to handle that error.

Let’s look at the timeout as a promise:

new Promise((resolve) => setTimeout(resolve, 3000))
  .then(() => alert("Hello"));

The first line constructs a promise that will be resolved when the timeout has been executed. The constructor of the promise invokes the function we’re passing in, giving it the resolve callback. The .then here is invoked on the successful completion of the timeout.

Which means we can also add more behaviour to the promise if we wish. Rather nicely, the then function can also accept a promise.

new Promise((resolve) => setTimeout(resolve, 3000))
  .then(() => alert("Hello"))
  .then(() => new Promise((resolve) => setTimeout(resolve, 5000))
  .then(() => alert("Hello again"));

Note, in the above, none of the background tasks return a value, so we’re not passing those values down to the .then. If they did, then it might look like this:

new Promise((resolve) => readUser(id, (user) => resolve(user))
   .then((user) => readUserProfile(user, (profile) => alert(profile));

And if we were working with nice functions that didn’t use callbacks, but natively returned promises, it might even be like this:

   .then((user) => readUserProfile(user))
   .then((profile) => findUserExpiry(profile))
   .then((expiry) => alert(expiry));

And let’s say it’s easy to add error handling with .catch and that any throwing within the process results in the error route being taken.

We can see that promises are a neater mechanism than callbacks.

Wait One Minute

Ask yourself this. If you were writing blocking code, where you can use the promises mechanism above if you wanted to… would you?

Is the above an excellent way to write code? or is it an excellent workaround for background code where we stop having control in this function the moment we invoke that background code?

Don’t get me wrong, the transformation code above is very convenient. Consider mapping and filtering a list:

const processed = ['A', 'B', 'C', 'D', 'E']
    .map(value => value.toLowerCase())
    .filter(value => !ignores[value])
    .reduce((a, b) => a + b, '');

This feels like the same basic functional programming as all the .then calls doesn’t it?

Except… the flow of control of the program goes to the next line of our function when this is calculated and we can USE the value constructed.

This fluent style of coding is great for making transformations. However, in practice, it’s not as easy to debug as if each line were laid out one after the other in a non-functional style.

Enter Async/Await

An async function is technically a glorified promise. If you call it, it runs in the background. It returns a Promise and you can mix them with the Promises API.

Whatever you do, don’t cross the streams!!!

You can mix Promises and async/await, but really really really try not to.

The effect of this pattern is generally that all the non-blocking code ends up in Promise returning functions tagged with async. Anything which wants to process the result of non-blocking code, joins the async crew. Anything which wants to fire and forget the non-blocking code doesn’t have to.

Genuinely non-blocking code is unaffected by this.

The result, though is that our database example earlier becomes:

// before
   .then((user) => readUserProfile(user))
   .then((profile) => findUserExpiry(profile))
   .then((expiry) => alert(expiry));

// within an async function
const user = await readUser(id);
const profile = await readUserProfile(user);
const expiry = await findUserExpiry(profile);

This is, in my view, massively simpler than the functional approach. It can be debugged by stepping over each line.

Error Handling

Any error handling in async/await is simply enclosed in try/catch blocks as per blocking code. If catch blocks hit blocking or non-blocking errors as they try to perform alternative paths, even that’s relatively straightforward.


There’s a natural evolution in languages from callbacks, through to promises, through to pseudo blocking code. More than JavaScript has made this exact series of steps.

The last stage is the pseudo-blocking code which is easier to reason about, and seems to flatten out the hierarchy of calls that are made some time in the future.

There’s also a great article on this on Hackernoon, which I always refer people to.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Wait For It…

Opinions expressed by Java Code Geeks contributors are their own.

Want to know how to develop your skillset to become a Java Rockstar?

Join our newsletter to start rocking!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Ashley Frieze

Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments
Back to top button