Even though I feel competent enough using them, I continue to dislike promises in any form, no matter how much syntactic sugar there is.
I wonder what do you do instead.
I Avoid Async/Await
161–170 of 242 posts
Re: I Avoid Async/Await
#162Maybe im wrong but i think await is not for everything it’s another tool, we as developer must known these tools, and when its better to use it or no
Re: I Avoid Async/Await
#163Earlier quoted context omitted.
Many devs unnecessarily nest Promises like that. async function getData() { return new Promise((resolve) => { const res = fetch(…); resolve(res); }); } The response above is wrapped in THREE different Promises! One from fetch, one manually created, and one implicitly created by `async`. The code above behaves exactly the same as function getData() { return fetch(…); } or even just fetch(…);
I'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?
This doesn't directly answer your question, but... something to watch out for is experienced developers can also struggle with promises and async code if they've spent most of their career working with sync code. And when we 'get' it, the difficulty of the journey is often understated. This stuff can be hard, so don't sweat it if it seems frustrating. (On the other hand, it may be easier if you don't have years of sync patterns to mentally set aside )
Re: I Avoid Async/Await
#164First off, async/await is promises. It's merely syntactic sugar. The point of async/await is not to never have the word "Promise" appear in your code. It's also not meant to be universally better than using Promises bare-bones. A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others: "We are taught", "our minds", etc. I can easily construe some hypothetical person with…
> A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others
This is literally 97.5% of all tech blogs, and a disappointing amount of content on HN front page.
I feel bad for the author. Nothing like asserting your ignorance on a blog. There's a time and a place for literally every language construct.
Re: I Avoid Async/Await
#165Promises are the most awful programming syntax I have ever come across. Await is sweet release from death as nowadays almost all apis are forced onto promises. Thank god xhr and websockets came before promises were mainstream, but for example webserial is absolutely horrible to use. Function callbacks are the best, though I wish JS would support function scheduling.
It's funny you say this because I have been promisifying xhr for years until fetch came along.
And these days I do the same when I want to simplify WebWorker communication. Promises are great
Re: I Avoid Async/Await
#166If 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 a…
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.
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?
Re: I Avoid Async/Await
#167[deleted]
Re: I Avoid Async/Await
#168Earlier quoted context omitted.
Many devs unnecessarily nest Promises like that. async function getData() { return new Promise((resolve) => { const res = fetch(…); resolve(res); }); } The response above is wrapped in THREE different Promises! One from fetch, one manually created, and one implicitly created by `async`. The code above behaves exactly the same as function getData() { return fetch(…); } or even just fetch(…);
I'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?
Not the parent, but I recommend understanding the event loop first: here [0] is a very good talk. Then, read the chapter on promise on javascript.info [1], as it explains the problems Promise set out to solve (callback hell), then as usual the excellent MDN article [2].
[0] https://www.youtube.com/watch?v=8aGhZQkoFbQ
[1] https://javascript.info/async
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
Re: I Avoid Async/Await
#169First off, async/await is promises. It's merely syntactic sugar. The point of async/await is not to never have the word "Promise" appear in your code. It's also not meant to be universally better than using Promises bare-bones. A lot of the argument appears to be the author extrapolating from his own lack of familiarity to others: "We are taught", "our minds", etc. I can easily construe some hypothetical person with…
async/await is _safer_ too, because part of that syntactic sugar is wiring up exceptions correctly and ensuring that a function only returns or rejects asynchronously and never synchronously. This prevents lots of bugs.
This article is bad, bad advice.
Re: I Avoid Async/Await
#170Earlier quoted context omitted.
> function getData() { return fetch(…); } I feel like there are advantages to making it `async function`, even if it's superfluous, because it signals to readers and to static code analysis that the function returns a promise. That's assuming the return type of fetch(...) can't be inferred by static analysis and developer tooling.
> the type of fetch() can't be inferred by static analysis That is preposterous.
It's not. One might assume it's Node fetch, but parent post was just using a specific example to make a general point. Fetch can be `any`thing.
Would you say the same thing about
function getData() { return mysteryFunction(…); }