4 ms·
From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that? Like, what's the equivalent of Promis
by xanderjanz 10y ago
From all my research, I feel like Promises end up making better code than async await. Am I the only one who thinks that?
Like, what's the equivalent of Promise.all with async/await? And how do tou do stuff synchronously after kicking off an async process?
- bsimpson 10y agoI haven't written any async/await code yet, but since it's just sugar over promises, wouldn't you just do "await Promise.all(...)"?
- dvlsg 10y agoYup. Promise.all() returns a new Promise which settles after every Promise in the provided array has settled (or throws after one of the provided Promises throws).
- skrebbel 10y agoI'm not sure you fully grok async/await then. Thing is, using async/await means using promises. You can't use async/await without promises. An async function returns a promise. Always. (in a way, `async` can be seen as something of a type annotation). If you want to use async/await with something that's asynchronous but not Promise based, you'll first need to convert it into a promise before you can async/await it. This is actually very elegant in my opinion: instead of proposing yet another way to do asynchronicity in JS, async/await fully embraces Promises, which you already know. Of course, this means that async/await also has all of Promise's downsides. For example, you can only resolve a promise once, so neither Promises now async/await make dealing with streams of asynchonous events any easier.
- jdc0589 10y agoI don't see that as a downside. Callbacks make sense for the pipelining portion of async streams. I usually wrap things up such that i set up my callback/event based stream pipeline, and then have a promise that gets resolves on completion/end. That way your stream code is 100% normal callbacks, and you still have promises/async/await for overall flow control.