Skip to content

What about Async, Await and Generators?

Daniel Levy edited this page Aug 17, 2017 · 8 revisions

Lions, tigers and bears!

If you have already read this projects' README you may think I'm a shill for the Promises lobby. I insist I'm not. Promises are only great when used as a function-chaining tool. Otherwise you end up entangling your logical steps. Avoid this by following the guidelines I lay out in this article: 4 interchangeable techniques for function chaining.

I have seen what feels like 1,000 articles on how Async/Await killed Promises, "victory!" Right? (links below)

Not so fast.

Simple examples don't prove any patterns' superiority, and most avoid key differences. Async/Await is currently hampered by 2 different function style for async vs. sync, await requiring .then() when outside an async function, plus the async keyword should be dropped. (If I had a magic wand, await is all you need for async and sync.)

Async/await fails to take advantage of array-methods. My 'Functional River' pattern combines what you love from Array.prototype, .map, .filter, .find, etc. with an identical interface for sync & async: .then(). [ Disclaimer: "My approach" === BluebirdJS ;) ]

Where Promises are Functional in nature, async/await is more imperative and tends to be less chain-able. This results in less parallelizable code - abandoning much of the advantage of modern JavaScript.

Perhaps most insidious about async/await and generators is that your first prototype will seem great. (Simple 'straw-man' examples are the bread & butter of blogs.) Maybe it's even "simple" to read (ahem, warning: your code always looks simple to you). Inevitably the imperative code encouraged by async, await (and generators) results in a soup of ad hoc logic and await'ed values. If you ask 10 developers to solve a problem this way, you'll get 10 different patterns.

Functional JS produces strikingly similar results between developers

While there are a few excellent articles appropriately skeptical of async/await, such as ES7 async functions - a step in the wrong direction

Most of the press out there seems closer to articles like From Promise API to Async-Await and 6 Reasons Why JavaScript’s Async/Await Blows Promises Away

The issue with these articles? They use weak Promise examples, and are usually too oversimplified to make any real conclusion.

Here's how I might refactor one of those straw-code samples:

image

Also, this kind of anti-promise "debugging sucks" rhetoric is getting old:

image

Essentially, async/await is a step backwards for JS & it's current patterns.


Alternate Examples

Comparison of Techniques

comparison-of-techniques