•July 27th 2018
Promises vs. Callbacks 🥊
Promises provide a simpler alternative for executing, composing and managing asynchronous operations when compared to traditional callback-based approaches. They also allow you to handle asynchronous errors using approaches that are similar to synchronous try/catch. Promises also provide three unique states:
- Pending - the promise’s outcome hasn’t yet been determined because the asynchronous operation that will produce its result hasn’t completed yet.
- Fulfilled - the asynchronous operation has completed, and the promise has a value.
- Rejected - the asynchronous operation failed, and the promise will never be fulfilled. In the rejected state, a promise has a reason that indicates why the operation failed.
When a promise is pending, it can transition to the fulfilled or rejected state. Once a promise is fulfilled or rejected, however, it will never transition to any other state, and its value or failure reason will not change.
The Downside 👎
The one thing promises don’t do is solve what is called “callback hell”, which is really just a series of nested function calls. Sure, for one call it’s okay. For many calls, your code becomes difficult, if not impossible, to read and maintain.
Looping in Promises 🎡
Error Handling 💣
Error handling with multiple nested Promise calls is like driving a car blindfolded. Good luck finding out which Promise threw the error. Your best bet is to remove the catch() method altogether and opt-in for a global error handler (and cross your fingers) like so: Browser: https://gist.github.com/nparsons08/ebaaf01a60e786a1c3c303167f1dede6 Node.js: https://gist.github.com/nparsons08/93d8b3fbea54fbd21c8486e89c51588c
Note: The above two options are the only two ways to ensure that you’re catching errors. If you miss adding a catch() method, it’ll be swallowed up by the code.
Callback Hell? 🔥
Callback-hell is a term used to describe the following scenario:
Note: As an example, here’s an API call that would get 4 specific users from an array.
Note: Here’s an example of the same set of API calls to retrieve 4 users from an array, in more than half the lines of code:
https://gist.github.com/nparsons08/022c7b85ddcfe85473d79edb7c105115 Fancy, right? 💃 And because Async/Await is built on top of Promises, you can even use Promise.all() with the await keyword: https://gist.github.com/nparsons08/e066f1162ebfdb2ce811d14b56a1e07f
Note: Async/await is slightly slower due to its synchronous nature. You should be careful when using it multiple times in a row as the await keyword stops execution of all the code after it – exactly as it would be in synchronous code.
How Do I Start Using Async/Await? 💻
Working with Async/Await is surprisingly easy to understand and use. In fact, it’s available natively in the latest version of Node.js and is quickly making its way to browsers. For now, if you want to use it client side, you’ll need to use Babel, an easy to use and setup transpiler for the web.
Let’s start with the async keyword. It can be placed before function, like this: https://gist.github.com/nparsons08/bf1ebddc1136dbdb8886b5fa757cc043
Why Is Async/Await Better? 😁
Now that we’ve gone over a lot of what Promises and Async/Await have to offer, let’s recap why we (Stream) feel that Async/Await is was a superior choice for our codebase.
- Async/Await allows for a clean and concise codebase with fewer lines of code, less typing, and fewer errors. Ultimately, it makes complicated, nested code readable again.
- Error handling with try/catch (in one place, rather than in every call)
- Error stacks make sense, as opposed to the ambiguous ones that you receive from Promises, which are large and make it difficult to locate where the error originated. Best of all, the error points to the function from which the error came.
Final Thoughts 📃
Happy coding! 🤓