Demystifying Async Programming in JavaScript

Demystifying Async Programming in JavaScript(blog.usebutton.com)

59 points by jasonmoo 9 years ago | 12 comments

ng12 9 years ago |

Am I wrong in feeling that callback hell is a symptom of bad design? In what scenario are you making four server requests before you can do something on a webpage?

I like async/await more for it's brevity than utility.

dcwca 9 years ago | |

"Callback hell" as it is described in this article is a symptom of not understanding how to flatten your code for readability. Deep nesting is a trap in every language, it's the programmers job to know how to write readable code.

http://callbackhell.com/

always_good 9 years ago | | |

The problem with callbacks isn't the indentation. It's that downstream dependent logic has to take place in the callback.

If you have two logical branches that share a downstream, now you have a fork with identical callbacks.

So reducing callback indentation comes at the expense of indirection. You're not changing the nesting at all. Usually just brooming stuff under the rug.

fenomas 9 years ago | |

> Am I wrong in feeling that callback hell is a symptom of bad design?

I think so, yes. Chaining together four consecutive web service requests might be a bad smell, but there are lots of other reasons to use async calls - waiting on a timeout, a worker, using IndexedDB, waiting on a user event or an animation, etc, etc.

In general if something can be done asynchronously it probably should be, so depending on the domain I'd say a lack of callbacks can be suspicious.

always_good 9 years ago | |

On the client, you are more likely to have a single API request. But on the server, you could be doing any mix of async things in a chain of dependencies + conditional logic.

Callback hell isn't a symptom of bad design. It's what happens when you have a lot of async function calls. Flattening callback hell often just contributes to callback hell with indirection, making it even harder to follow.

But thankfully we have promises, now.

jasonmoo 9 years ago | |

microservices. the struggle is real.

beaconstudios 9 years ago | | |

Overuse of microservices is definitely a valid case of bad design.

jasonmoo 9 years ago |

It's interesting I think having an understanding of the history of javascript concurrency is almost a prerequisite to using it correctly. I wonder how new people approaching the language for the first time find it.

brito 9 years ago | |

I find two camps: 1. those who need to produce backwards-compatible code, avoiding or not thinking about new features 2. those who can/want to use new features

Camp 1 has the problem of continuously importing kitchen sinks instead of polyfills, which would allow getting into camp 2.

Camp 2 is essentially a luxury of time, thus rare. It already requires mental commitment, which may be scarce after a day of battling bugs for IE.

mvindahl 9 years ago | |

I think that as a beginner you can get far with async/await without truly understanding it. I also think that at some time the abstractions will leak and your head will spin madly.