Cleaning up your asynchronous code with await

REPLs have traditionally had a difficult time allowing you to interact with asynchronous code since they encourage a coding style where you evaluate expressions and use those results in the next field. But if you are using promises or callbacks, this breaks down because these results exist only in the callback, not the next line:

In RunKit, you can use top-level await to get the same behavior of synchronous code.

Now we can treat this code as synchronous, despite the fact that the code is still executing asynchronously.

Let's look how. It helps to have a more complex example, where we need to do a few asynchronous operations in sequence. You can see how await, promises and callbacks achieve the same results, but the await style works better in a REPL:

Here, we use await on lines 4 and 8, and the results from each request remain in scope.

Promises appear to be cleaner than nested callbacks, but not without a new syntax and scope confusion caused by passed functions.

When using callbacks, the error, body and response are only in the callback's scope, so we nest a second callback to perform another got call using data returned from the first.

Remember, await expects a promise so you can either write your own or use one of the many libraries that natively supports promises, and npm is full of packages that add promise support to existing libraries. Here are a few of our favorites:

Further Reading