If you’ve spent any time coding in javascript on the back end of an application, you’re likely familiar with “promises”. If you aren’t familiar with promises as they relate to javascript, or code, they are essentially used to represent the eventual invocation/success/failure of an asynchronous function. An asynchronous function or operation is one that does not run at the time of interpretation, and can run in parallel with other operations. Synchronous code on the other hand runs one at a time without any ability to send more than one request at a time.
Asynchronous programming is at the heart of our backend technologies as it allows for us to designate “nets” of asynchronous code to catch incoming or outgoing requests as well as send multiple requests at any time.

The anatomy of a promise

follows that of a function for the body, however we can use .then at the end of the function call to designate what happens next to the returned value of the promise. We simply name the returned value whatever we want and manipulate it in our .then block to make a promise chain. This can be anything from displaying something to a user on the client side to sending another request to another endpoint. When working with promises and asynchronous code, we need to ensure a good development experience by handling errors. With the setup of promises we need to handle errors that may arise as if we don’t, we will simply not get any information back to debug our code. We do this by using a .catch block after our .then block to handle any errors that may arise from our promise resolution.

The beauty in promises is that they are always there, waiting to be used by our applications or users to handle the magic behind the scenes. All this to say there are issues that come from traditional promise chains. This is an issue that pertains to a lot of asynchronous code, that being illegibility. Asynchronous code can be large, daunting and difficult to read or follow. Programmers young and old have experienced the triangle of doom, a tale as old as time, stuck in callback hell.

This is where Es6 saves the day.

Upon the release of ES8, the introduction of async/await syntax graced us. A new way to write promises that severely reduced the difficulty and intimidating stature of traditional promises. Async / await are essentially the same as promises but offer shorter, more concise code. It helps make the jungle of asynchronous code much more manageable, it may not seem like much, but when you’re looking at thousands of lines of async code, the benefits this syntax offers is unparalleled. This new syntax can be difficult for new programmers to pick up on top of the already relatively confusing idea of how promises work. The main syntactic difference is that you must declare a function asynchronous with the async keyword in the function declaration, and the blocks for then and catch would now be try and catch. Along with this comes the ability to use the await keyword to tell our program in these blocks to await the resolution of a promise and assign it to a variable, which also does away with the required use of Promise.all for multiple promises. All in all, there are some minor differences between the two, but it’s worth learning to save on the potential time waste and headache that can come with gigantic promise chains.