Hacker News new | past | comments | ask | show | jobs | submit login
Async/await: It’s Good and Bad (medium.com/benlesh)
21 points by shawndumas on Feb 27, 2016 | hide | past | favorite | 5 comments



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

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


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


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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: