Promise the “Hello, world!” and Await the Response
Promises Vs Async/Await
In this blog, I attempt to reason out first, what is Async/Await is, how it differs from its predecessor, promises, and how and when to use both. I will be doing this assuming a base understanding of asynchronous functions and why they are important. The initial aim of this, like most of my other blogs, is to take a subject that I don’t have the sturdiest understanding of and see if I can make it clear to myself and maybe someone else who stumbles across this.
I like to think about Javascript as an ancient European city. As the population grows and things become more populous the city never demolished and starts fresh, instead, it keeps building on top of what’s already there taking what was good and bad from before and making it work for the modern world. Javascript, from its somewhat humble beginning back in the mid-’90s, grew rapidly as developers look for ways to make the websites more dynamic. Then in 2005 when the AJAX web model was introduced Javascript’s popularity skyrocketed. As things grew and people demanded more the language grew and evolved. An example of this is the for loop. From the for loop, we got things like the for..of, for..in, .forEach, while. All of these functions can be accomplished with the basic for loop but the ease of writing, simpler code to write, and easier ways to utilize call back functions.
This was a roundabout way to introduce the topic but in ES2017 Async/Await syntax was introduced, then if we dig down a little deeper we see promised introduced in ES2015, and before that, we were working with callbacks to handle how and when we wanted our code to execute. When comparing async/await vs promises it is important to note that async/await was built directly on top of promises, it is ‘syntactical sugar’.
We are not going to dig too deep into this idea right now, but one nifty thing javascript and a lot of other coding languages can do is run through their code asynchronously. What I mean by this is that when your browser is presented with javascript code, it will start reading the code like you are reading this blog, top to bottom, right to left, but when it comes to a piece of code that it knows it will take some time to execute it will put it on the back burner keep going through the code and come back to it when it has more time. This can be illustrated with the classic example seen below.
While this is good and all, what does this have to do with promises and this async/await thing? Well, the setTimeout function is not technically a promise, it is a method that takes a callback function, it illustrates what I mean by javascript running asynchronously.
…
When working with javascript there will come a time when you want to run some code and then run some more code with the results of what you previously did. This is good and all to stack the code on top of one and another until the compiler decided that the function you wrote is going to take too much time and it skips over it goes to the second function, which relies on information from the first and then freaks out because it is super confused and doesn’t know that to do. This is where promises come in. When using promises you can tell the compiler to do a function and only once it is done with that, it can move on that second piece that relies on the info from the first.
A very common example of using promises that I have come across quite often is when making fetch calls to an API.
In the above example, we are fetching data from an API endpoint. Then we want to do something with the data, in this case, we want to parse the string we get from the API into JSON. After that, we would like to do something with this JSON data in our code. The fetch call returns a promise to deliver something and only when the promise has been fulfilled the rest of the code will be executed. Using the .then method is called chaining and each one returns its own promise to be fulfilled.
While slogging through my coding boot camp I learned about promises and have been using them quite frequently making CRUD applications but for one reason or another, the async/await syntax has alluded me. I have known it exists but never really know how or why to use it. All of that changed this morning. I was working on my latest React application and wrote this piece of code.
Yeah, it’s there, it works alright but not the prettiest or most intuitive piece of code ever written. The application this is for is a sort of bar game finder, say you are in a certain city and would like to play some pool, or if you are looking for a local watering hole where you can grab a pint and play some PacMan, this app is for you. This snippet is to pull data from two different tables in my database, if this is not best practice, please reach out, still learning. But anyway I am trying to do multiple asynchronous functions at the same time and then do work on both of them. This is what async/await was made for. Here is the same code but with the async/await syntax.
Much better, right? I think so. Under the hood, they are doing the same thing but with this method, it is easier to code and easier to read. And as an aspiring developer, I think this is what it is all about. I think I will still use the chain .thens when the situation arises for something simple but with async/await we broaden the scope of what is possible and at the same time make the code more approachable
Further reading:
