Skip to content

What about Async, Await and Generators?

Daniel Levy edited this page Jul 8, 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?

Not so fast.

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 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.

Simple examples don't prove any patterns' superiority, and currently the Async/Await feature itself is too flexible. The emerging patterns are poorly thought-out, and feel like a step backwards toward synchronous & imperative code. This results in less parallelizable code - abandoning much of the advantage of modern JavaScript.

Perhaps most annoying, the initial version may seem great - even if only single-threaded. Maybe it's even simple to read. Inevitably as time passes, features are added, and before long you have a mess. (See scope creep: Let's add a permissions check, stick it before profile.update(); add a logging call there too... - please just stop smashing random code together & committing.)

Clone this wiki locally