Promise to Await Async

If you are still using promises and avoiding its replacement, this article on Six Reasons to Await/Async instead of Promise gives good reasons to move forward in asynchronous JavaScript. It is old news that current frameworks transpile before devices and browsers ever see the code we author. With that in mind, why would we not write the cleanest code we can while keeping our eyes on the near-term horizon of JavaScript functionality. Although the article references await/async support in node 7.6+, the reality is babel and typescript each have their own ways of processing await/async functions that may involve generators, modules and old-fashioned promises in their compiled output.

Why should we fix something not yet broken? While users of pug may be jaded, and users of coffeescript see its features becoming native in one framework after the next, the attraction to await/async is that it is almost universally embraced and expected to grow in usage due to its conciseness. One could argue that transpiling await/async can create a degree of code bloat, its terseness and existing or coming inclusion in all major browsers should moot that argument.

If you currently transpile your code, replacing promises is something you can begin today without breaking anything. That said, check out a new branch just to make sure!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s