
Async/await: It’s Good and Bad - shawndumas
https://medium.com/@benlesh/async-await-it-s-good-and-bad-15cf121ade40#.t59d6u4ws
======
callahad
The author has a beef with the ES5-compatible code that Babel emits for
async/await, but you don't have to go that far.

If you can get away with ignoring IE and Safari, the latest versions of Edge,
Firefox, Chrome, and Opera all have native support for promises and
generators, which can implement async/await style concurrency much more
tersely: [https://babeljs.io/docs/plugins/transform-async-to-
generator...](https://babeljs.io/docs/plugins/transform-async-to-generator/)

There's also Kneden ([https://github.com/marten-de-
vries/kneden](https://github.com/marten-de-vries/kneden)) which, combined with
a Promise polyfill, should transpile async/await into relatively clean chains
of promises.

------
acjohnson55
I don't really buy the con of async/await allowing you to write really long
functions. You can do the same thing in completely synchronous logic.
Additionally, I don't really buy the chopping up of a cohesive process into
itty bitty functions. Certainly small, simple function are nice, but when
small for smallness sake, you basically end up with unreadable spaghetti code.

A benefit the author didn't quite touch on is what a boon async/await is for
branching processes. I've got a block of logic that takes credit card info for
Stripe, and it needs to validate user info, tokenize payment info, add it to
the user model, and then add the tokenized card to the Stripe customer
associated with the card. There are a lot of places this can go wrong or data
can fail a validation. In promises, branching mid-flow is a huge pain.

The much more interesting issue with callback-driven approach to async, no
matter what the sugar, was raised by
[http://journal.stuffwithstuff.com/2015/02/01/what-color-
is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/).

------
martinbooth
The fact that the generated javascript doesn't look as neat is a pretty poor
argument. Does the author avoid other language features that get "lowered"
([http://ericlippert.com/2014/04/28/lowering-in-language-
desig...](http://ericlippert.com/2014/04/28/lowering-in-language-design-part-
one/)) into less elegant code as part of the execution?

In time, we'll not see this code as it'll all happen within the javascript
engines, but all features of javascript are still abstractions over lower
level code.

How about writing a loop over asynchronous functions? Now that is unpleasant
to look at, and most examples I've seen use recursion which is pretty
limiting.

That is one of the best reasons to embrace async/await

------
spo81rty
Does it really matter what the generated code looks like?

We use Typescript and I don't care what the final Javascript looks like. I
don't plan to ever touch that code manually.

~~~
tylerlh
It matters if you're concerned about keeping the size of your JS payload in
production to a minimum. In the Babel example, you're looking at multiple
times more lines per async function compared to promises, plus extra execution
via regenerator when compiled to ES5.

That said, I'm a fan of async/await -- just not yet for projects where I need
to optimize for filesize.

