The technology we (humans) use has conditioned us to be impatient. We (again, humans) have become so easily frustrated by non-instantaneous load times that we forget that the technology we’re using is a luxury. Most people abandon whatever web page they were trying to access if it doesn’t load in under 2 seconds — but sometimes it takes longer than that for a request/response cycle to successfully execute. Enter asynchronicity…
Asynchronous processes are awesome. They allow humans to accomplish a ton of things in not a ton of time. A dictionary would tell you that asynchronous means: “not happening at the same time” or some variation of that, which, if you break down the etymological components of the word is a spot on definition…. “a” = non; “syn” = together (Greek); “chron” = time (also Greek), “ous” = characterized by (latin).
In programming asynchronous processes are those that allow programs to execute tasks (lines of code) while other more time consuming tasks are happening in the background. When I first encountered the concept of asynchronous processes in programming I thought, “hey, wait, this is betraying the original meaning of the word asynchronous”. I was wrong.
Imagine you are painting the walls of a room with 3 coats of paint. This room has 4 walls, and it takes an hour for a coat of paint to dry, BUT it only takes you 20 minutes to lay down one coat of paint on one wall. Naturally, you paint one wall and move on to the next one while the first is drying. By the time you have laid down your first coat on all 4 walls, the first wall you painted should be dry and ready for the next coat. The sequence of laying down a coat, and letting the others dry at the same time is what makes this an asynchronous process. Yes, tasks are happening at the same time, but they don’t require your action and attention at the same time.
The same can be said for asynchronous code. If your code makes a request to a server, it’s going to take a while for the server to receive the request, figure out what kind of request it is, parse the information that comes along with the request, perform some action based on the previous 2 steps, then send back a message to the browser signifying whether or not the request was a success. That’s time wasted… if your code is waiting on the response in order to move on and execute the next line of code. That’s where promises come in.
You might want your code to spend that wasted time accomplishing other things, or you might want your program to just pretend the request is going to be successful and carry on with its business. Promises allow you to do both of those things. A promise is basically a placeholder for information that the server may or may not end up returning. Promises can be implemented to execute code conditionally based on whether or not the request/response was successful. The beauty of promises is that your code doesn’t have to wait around on a response in order to continue on about its business. This makes rendering dynamic content to a page way faster, and considering our attention wanes after 2 seconds, that time really matters.
This begs the question: is it better to design UI’s that wait around for a successful request/response to the server before anything on the page is manipulated? Or is it better to just assume that the request/response is going to be successful and manipulate content before users have a chance to get bored or frustrated and move on?
Well that depends… are you a pessimist? Or an optimist?