3 ms·

If you're doing nothing in between your async calls, using .then/.catch might be simpler. As soon as you need to introduce local variables and complex control

If you're doing nothing in between your async calls, using .then/.catch might be simpler. As soon as you need to introduce local variables and complex control structures, not having shared closures between your .then methods becomes extremely limiting. Hence, the async/await sugar. About having to add await to ensure your error is handled with the try catch — not putting an await before a promise is something I use all the time. Being able to store tasks/promises and reuse/await them later is a clear advantage to other types of async code (such as coroutines).

too_root 4y ago
I agree. I think the article takes a simplistic view of the use cases in an effort to make the post consumable but in doing so, misses some of the point behind the syntax.
Aeolun 4y ago
> Being able to store tasks/promises and reuse/await them later is a clear advantage This sounds like horrible spaghetti. I can understand you might need to do it in exceptional circumstances, but I wouldn’t make a habit of it.
- zebracanevra 4y ago
  99% of the time you'll be storing promises in order to await on them in the same async method. Those other 1% of times make for quite intuitive solutions, I think. For example, a cache. Most caches are request => already finished response, but with a lookup of promises you can easily do request => in-progress responses, for de-deplication.
- yourad_io 4y ago
  Graceful shutdown & startup are two use cases that I used this for, just today. When my express server gets a SIGTERM I want it to stop accepting new requests but finish pending requests before exiting. Likewise during startup, the HTTP server is currently up before all resources are available - DB backends and the like. So I await a .ready promise before all requests iff we are not inited. It can be abused into spaghetti for sure, but actual use cases are not that exotic imho
jonathanlydall 4y ago
Completely my feelings too. He doesn't actually address this, and it is actually the really painful part about promises which async/await makes infinitely better. I have had cases where converting .then(...) code to async/await made the code infinitely easier to understand/reason about and made it trivial remove bugs which were present due to the complexities of dealing with control flow logic. It strikes me that the author is just already "used to" promises and as such is trying to justify their preference for them with examples which they believe "prove" that promises are "better", but actually fail to do so. For every single one of their examples, async/await is no worse, if not better. For example, their argument about inadvertently serialized work with the the two save calls. They are claiming that ".then()" is more obviously serializing than the "await" keyword, which is a highly subjective claim. If there is a problem here, it's that some developers don't understand/know about all the asynchronous tools which are available and so are unaware of the option of using Promises.all(...). Another argument for async/await compared to promises is the following: try { await doSomething(); } catch() { // Do a particular error handling for doSomething() failing } try { await doSomethingElse(); } catch() { // Do a different particular error handling for doSomethingElse() failing } What's the best way to reproduce this in promises only land, for example, does the following work? doSomething() .catch(() => { // Do a particular error handling for doSomething() failing }) .then(() => doSomethingElse()) .catch(() => { // Do a different particular error handling for doSomethingElse() failing }); I think it works, but I honestly don't know for sure offhand and to be sure I would need to check the documentation for promises, whereas for the async/await approach, there is no question. And if the above doesn't work, then I would have to call the .then() from inside the first .catch() block, which is awful code to read and interpret.
- alerighi 4y ago
  It's the same code. Async/await is just syntactic sugar over the promise syntax. To me depends on what you are doing, there are cases where using .then()/.catch() and .finnally() makes the code more concise and simpler than using async/await.
- beardedetim 4y ago
  .catch() returns a promise so you can call the then method on it again, yes. If you throw from either catch or then it will trigger the next catch method.
madeofpalk 4y ago
One thing I really like async/await for is you can use them in for-loops. It makes it significantly easier to do async work in what was previously very synchronous.
- ElFitz 4y ago
  I thought await in loops was a big no no, unless it has changed since I last checked? Doesn’t it remove any opportunity for parallelism, making the loop take much longer than it would with a Promise.all? Or am I missing something?
  - yourad_io 4y ago
    Sometimes you want to do things sequentially, so for..of x { await } is the way to go If you want parallelism: await Promise.all(x.map(...))
  - madeofpalk 4y ago
    You're right(ish) - the async functions would not run in parallel. But sometimes that's either fine, or I don't want them to run in parallel.
    - ElFitz 4y ago
      It’s funny; I never thought of it as a desirable behaviour. To each their own!

too_root 4y ago

I agree. I think the article takes a simplistic view of the use cases in an effort to make the post consumable but in doing so, misses some of the point behind the syntax.

Aeolun 4y ago

> Being able to store tasks/promises and reuse/await them later is a clear advantage This sounds like horrible spaghetti. I can understand you might need to do it in exceptional circumstances, but I wouldn’t make a habit of it.

zebracanevra 4y ago
99% of the time you'll be storing promises in order to await on them in the same async method. Those other 1% of times make for quite intuitive solutions, I think. For example, a cache. Most caches are request => already finished response, but with a lookup of promises you can easily do request => in-progress responses, for de-deplication.
yourad_io 4y ago
Graceful shutdown & startup are two use cases that I used this for, just today. When my express server gets a SIGTERM I want it to stop accepting new requests but finish pending requests before exiting. Likewise during startup, the HTTP server is currently up before all resources are available - DB backends and the like. So I await a .ready promise before all requests iff we are not inited. It can be abused into spaghetti for sure, but actual use cases are not that exotic imho

jonathanlydall 4y ago

Completely my feelings too. He doesn't actually address this, and it is actually the really painful part about promises which async/await makes infinitely better. I have had cases where converting .then(...) code to async/await made the code infinitely easier to understand/reason about and made it trivial remove bugs which were present due to the complexities of dealing with control flow logic. It strikes me that the author is just already "used to" promises and as such is trying to justify their preference for them with examples which they believe "prove" that promises are "better", but actually fail to do so. For every single one of their examples, async/await is no worse, if not better. For example, their argument about inadvertently serialized work with the the two save calls. They are claiming that ".then()" is more obviously serializing than the "await" keyword, which is a highly subjective claim. If there is a problem here, it's that some developers don't understand/know about all the asynchronous tools which are available and so are unaware of the option of using Promises.all(...). Another argument for async/await compared to promises is the following: try { await doSomething(); } catch() { // Do a particular error handling for doSomething() failing } try { await doSomethingElse(); } catch() { // Do a different particular error handling for doSomethingElse() failing } What's the best way to reproduce this in promises only land, for example, does the following work? doSomething() .catch(() => { // Do a particular error handling for doSomething() failing }) .then(() => doSomethingElse()) .catch(() => { // Do a different particular error handling for doSomethingElse() failing }); I think it works, but I honestly don't know for sure offhand and to be sure I would need to check the documentation for promises, whereas for the async/await approach, there is no question. And if the above doesn't work, then I would have to call the .then() from inside the first .catch() block, which is awful code to read and interpret.

alerighi 4y ago
It's the same code. Async/await is just syntactic sugar over the promise syntax. To me depends on what you are doing, there are cases where using .then()/.catch() and .finnally() makes the code more concise and simpler than using async/await.
beardedetim 4y ago
.catch() returns a promise so you can call the then method on it again, yes. If you throw from either catch or then it will trigger the next catch method.

madeofpalk 4y ago

One thing I really like async/await for is you can use them in for-loops. It makes it significantly easier to do async work in what was previously very synchronous.

ElFitz 4y ago
I thought await in loops was a big no no, unless it has changed since I last checked? Doesn’t it remove any opportunity for parallelism, making the loop take much longer than it would with a Promise.all? Or am I missing something?
- yourad_io 4y ago
  Sometimes you want to do things sequentially, so for..of x { await } is the way to go If you want parallelism: await Promise.all(x.map(...))
- madeofpalk 4y ago
  You're right(ish) - the async functions would not run in parallel. But sometimes that's either fine, or I don't want them to run in parallel.
  - ElFitz 4y ago
    It’s funny; I never thought of it as a desirable behaviour. To each their own!