Paul Cowan
May 20, 2020 ⋅ 4 min read

async/await is the wrong abstraction

Paul Cowan Contract software developer.

Recent posts:

Bulma Css Adoption Guide: Overview, Examples, And Alternatives

Bulma CSS adoption guide: Overview, examples, and alternatives

Explore how Bulma CSS simplifies frontend development with its ease of use and customizable, responsive, pre-designed UI elements.

Timonwa Akintokun
May 23, 2024 ⋅ 10 min read
Using Mountaineer To Develop A React App With Python

Using Mountaineer to develop a React app with Python

Develop a React app with Python using the Mountaineer framework for building a simple app with integrated your frontend and backend database.

Rosario De Chiara
May 23, 2024 ⋅ 7 min read
Enhance CSS View Transitions With Velevette

Enhance CSS view transitions with Velvette

Velvette is a utility library developed to make working with view transitions easier.

David Omotayo
May 22, 2024 ⋅ 9 min read
Six Carousel Components For Modern Frontends

6 carousel components for modern frontend languages

Carousel components have become an effective technique to organize and display it content to users.

Isaac Okoro
May 22, 2024 ⋅ 10 min read
View all posts

21 Replies to "async/await is the wrong abstraction"

  1. “there is absolutely nothing to support cancellation in async…await”

    Well, of course there isn’t. The Promise itself doesn’t support cancellation in the way that you seem to expect, and async/await is just syntactical sugar on the Promise API.

    The code you share doesn’t fix this deficiency. It just adds cancellation support into an arbitrary multi-promise dependency. async/await isn’t “the wrong abstraction”. It just isn’t sufficient for what you’re trying to do. 🤷‍♀️

    Less click-bait titles. More sharing of cool code! 😉

  2. Agreed. This article is like someone complaining that cookies are dangerous because they have a peanut allergy.

    First, something isn’t bad just because it doesn’t suit your personal/immediate needs.

    Second, you’re blaming a feature for a challenge caused entirely by one of its parts.

    Here is an article that covers this topic in a sensible fashion, from which this one seems a lazy ripoff.


  3. Paul’s point was exactly what the title said. async/await is the wrong abstraction because it leads to incomplete solutions. It punts on one important aspect of async programming and occupies a valuable API surface.

  4. > It just isn’t sufficient for what you’re trying to do. 🤷‍♀️

    I think Paul’s point is not that Promises are a bad abstraction. It’s that `async/await` doesn’t scale. It’s worthing bearing in mind that async/await isn’t just any old abstraction like a `Map`, `Blob` or `ServiceWorker`. It’s literally something that has been baked into the platform at the lowest level: the very grammar by which we express our programs.

    Cast in that light, I think his point that there was a missed opportunity to expand flow control at the structural level to accommodate very common and irksome flow control patterns really does stand. Imagine if there had been an implementation of `try/catch` without the concept of `finally`. Would `catch` be implicity bad? Of course not. But it would mean a lot of headaches and workarounds in the cases where it’s needed, and it would me that practitioners would be left with the feeling that the language designers had come close, but fell ultimately fell just shy of the mark.

  5. I agree this post is kind of clickbait to advertise his plugs. Pretty useless info without providing any solution other than some generator library.

  6. Clickbait, biased and dumb content for showing nothing else than another tool. Instead of solving the problem you claim … Sad…

  7. the premise here seems to be that having an opposing view is click bait. i have clearly stated the problem i have used a simple example followed by a codesandbox which i wrote but i suspect most did not read that far and highlighted a cutting edge package. click bait? really. so many posts hauling async await as the second coming so i added some balance. dear oh dear. how sad

  8. I honestly have no idea what the author is talking about. I try/catch await all the time.

    While javascript doesn’t have threads, you’re not going to get task cancellation, and that’s something a developer advanced enough to think he has an opinion about this would be expected to understand.

  9. No examples? No other pattern? Wth is daga1 talking about. await is inherently tied to the pattern of the cancellation token, the fact that you were too lazy to pass won down through doesnt make this abstraction useless. To make this serious youd have to inform why cancellation tokens wouldnt be a solution.

    Just cause generators are a more elegant solution doesnt make await crap. In a few weeks/months/years youll stumble upon the concept of async generation (see IAsyncEnumerable) and be back to saying await has a place with generators too…not sure when that will make it to ecmascript though

    That is why this is click bait

  10. Async/Await is literally syntatic sugar over generators which is the correct abstraction. This article is like complaining that array.push is bad because it doesn’t handle multiple arguments. There is a slightly more complex version of the tool that is perfectly capable of performing the task you’re looking for. The reason Async/Await was made as streamlined as it was is simply because the vast majority of use cases did not require cancellation and therefore made the prospect of juggling another cancellation variable impractical. You solve issues for the masses and provide more powerful tools for the times those mass solutions don’t cover the use-case.

  11. Async/Await wasn’t meant to be the end-all be-all of asynchronous programming in JavaScript. Generators are still valid, as are callbacks. There are more powerful tools designed to support the use cases you are looking for without the streamlined nature of Async/Await. This feature was designed to drastically simplify the majority of web-tasks to do with Asynchronous programming. The vast majority of asynchronous code written for the web is literally do this, then this, then this. Cancellation is only a consideration in a fraction of a fraction of applications and so jamming that into Async/Await didn’t make sense as most developers would never use it and would just discard the cancellation reference as soon as they could. Generators are a lower level and more powerful abstraction specifically there to support more demanding use-cases such as yours. Because truthfully, once you need cancellation, you start wanting progression updates, real-time status capabilities and more because you are no longer firing off an asynchronous pipeline, you are managing an asynchronous process that your consumer is engaging with.

  12. Programmer doesn’t read the requirements properly.
    Programmer doesn’t want to use a simple queue.
    Programmer blames async, await, his dog 🐕 and his cat🐈.

  13. It’s worth noting that when Apple implemented its own async / await primitives for Swift, they went with something closer to what Paul is advocating rather than JavaScript’s version. This is because automated task cancellation is something you will almost always need to build concurrent systems that are correct, and the lack thereof means the introduction of non-trivial ad-hoc workarounds like abort controllers that have to be passed around explicitly.

    Swift, Java, Kotlin, and a growing number of languages are coming to this realization and have provided, or are in the process of providing the primitives to do so. JavaScript *could* have done this, but it would have meant basing async/await not on promises, but on some form of cancellable task.

    For those coming to this post just now: the issues identified here are applicable to any language you happen to be working in, and when you encounter them in JavaScript, Paul has pointed out real, practical solutions.

    For those who knee-jerked into claims of “clickbait” without doing the intellectual work to actually understand the position before attacking it: history is now beginning the process of not treating your takes very kindly. I hope you can learn that when it comes to a comment section, a single question is worth a thousand opinions.

    See https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md for reference

Leave a Reply