Explaining Asynchronous Javascript

Have you ever wondered what buffering meant or when you saw the fan whenever you were waiting for the website to load. One might say, “oh my computer is thinking.” There is a chance that what is actually happening is asynchronous computing, there could be a function either being executed or waiting to be executed in order for the website to work thoroughly by processing data such as through fetch request that is waiting to fulfill or reject a promise or you’ve clicked or submitted a feature, or it’s answering a callback function. As described, Asynchronous Javascript includes callbacks, promises, and async/await.

If you’re brand new to Javascript, this article may be going completely over your head. Most people aren’t searching anything remotely related to asynchronous computing. So, if you’re here, that means you may know a thing or two.

To start, Asynchronous Javascript was created for application performance and responsiveness. It originated from nested functions as callbacks.

Asynchronous programming is a form of parallel programming that allows a unit of work to run separately from the primary application thread(
or call stack). For example, in order for you to continue to use a website and while you’re searching or continuing onto a new page, behind the scenes, that website is connecting the dots and completing tasks.

Why we might use Asynchronous Javascript, a hypothetical example.

Say you want to bake bread and synchronous computing only allow you to begin by reading the instructions, wait for the oven to full preheat, knead the bread, get the ingredients mixed with the dough, wait for the dough to rise then put the bread in the oven, wait for the bread to bake and then take it out and then clean up your mess. If you had to do this in exact order, it would take a long time.

Each function above would be blocking the call stack or main thread.

Asynchronous programming would be while you wait for your oven to pre-heat, you’d be able to get the ingredients together, knead the bread, wait for it to rise and while you wait for it to rise, you could clean up your mess, use the bathroom, put away any dishes, then once you hear the oven alert you that it’s been preheated, you can put the bread inside and then go take a nap while you wait for your bread to fully bake.

The first function, recipeInstruction that’s taking in the URL example could in theory be the callback function to another function that represents the fetch request. fetch() taking a single parameter — the URL of a resource you want to fetch from the network — and returning a promise. The promise is an object representing the completion or failure of the async operation. Neither of the possible outcomes have happened yet, so the fetch operation is currently waiting on the result of the browser trying to complete the operation at some point in the future(MDN).

Now if you wanted something to happen after the async behavior of the fetch request has happened, in the above scenario, say before putting the bread in the oven, you’d have to wait for the oven to preheat first. This is where .then would come in. Calling preheatOven wouldn’t ensure that the oven has preheated before the 2nd function is called, unless the first function is executing async code such as a fetch request.

Obviously, someone might not be this productive when baking bread. But you get the idea that it’s more efficient to use asynchronous computing in order to get other functions executed while waiting on another function to be executed.