-
Notifications
You must be signed in to change notification settings - Fork 25
What about Async, Await and Generators?
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.
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:
- Steps
- Bonus Material