I think, therefore I’ll async/await

Don’t let synchronous code upset yourMomma and spoil Thanksgiving

Javascript is a single-threaded programming environment. That means that typically your Javascript code can only be doing one thing at any point in time. Generally this restriction isn’t an issue for many operations, like adding numbers or updating a variable in memory; generally a task that can be completed in one pass through Javascript’s event loop.

The issue with a single thread becomes clear when a program needs to perform an operation that may take a long time to complete, like reading a large file from a disk or uploading a file to the cloud. While the slow operation is taking its time, the queue of pending operations is stalled or “blocked” and everything (at least in this program) grinds to a halt.

If we as humans perceive a program to be running slowly, imagine what your code and laptop must be feeling…

This is where asynchronous programming comes in: Javascript promises that an operation will resolve (successfully or maybe not) at some time in the future, so you (and your code) don’t need to wait around and can make better use of your time by doing something else. When the operation finally ends, then it can send its results, or (helpfully) throw an error message if something goes sideways. Your code can then be on its way.

As an example, let’s use (the tried-and-true) setTimeout inside of a promise. Let’s call our the asynchronous function yourMomma:

yourMomma takes one argument, youBestNotBeSassinMe, and returns her reply after 2 seconds. Yeah, yourMomma is slow while she’s figuring out if you’ve got a smart mouth, and because she’s making a promise you best believe she’s gonna keep it sometime in the future. You can go about your business (for now); she’ll let you know. So, yourMomma can also be called asynchronous.

In Javascript, we can interact with yourMomma in a couple of ways:

We can use thenables

… or the form I prefer: async/await:

Want to read this story later? Save it in Journal.

Both of these forms work exactly the same (yourMomma doesn’t care), but a simple example like this doesn’t illustrate the benefits of async/await.

So, imagine if you wanted to perform a chain of operations (where each operation takes significant time) and the results returned from each step are used in the following step. Using the thenable form with slow folk like yourAuntie, yourUncle and yourGramps that operate much like yourMomma:

… or using async/await

I find that async/await is easier to work with if the any step needs to conditionally decide what it needs to do based on the results from the previous step.

What if, depending on how yourAuntie is feeling and what yourMomma said to her, yourAuntie wanted to talk to yourGramps instead of yourUncle? With thenables, the code (not to mention Thanksgiving) could get ugly:

Messy, right?

But with async/await, I think it’s easier to follow:

if (mommaSaid === "Not Today!"){
const auntieSaid = await yourAuntie("I'm out")
const zzzZzzZzz = await yourGramps(auntieSaid)
} else {
const auntieSaid = await yourAuntie("I'll have pie")
const uncleSaid = await yourUncle(auntieSaid)
}

Ok, still not the best example, but imagine if you needed conditionals (and error handling!) for results from yourMomma, yourAuntie, yourUncle and yourGramps?

Life gets hectic quickly, and you don’t want the whole family waiting around. Anyway, the food’s getting cold; somebody wake up Grandpa.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store