Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Avoid Async/Await

uniqname.medium.com

Post reply on HN
Print view View original

41–50 of 242 posts

Re: I Avoid Async/Await

#41

Post by Waterluvian »

chmod775 wrote: post #24

First 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…

TypeScript even forces you to acknowledge this as the explicit return type of an async function is a promise.

Re: I Avoid Async/Await

#42

Post by __ryan__ »

This article takes serious mental gymnastics to follow.

The main argument seems to be that an engineer with a working mental model for basic promise chaining will be unable to translate that to async/await, which is effectively syntax sugar for the same thing.

The author says that multiple calls to .then() is a cue that the code is occurring serially, and the new keyword await somehow isn’t.

There’s a time and place for raw promises, but this article hardly touches on anything actually wrong with async/await.

I’ve worked with engineers who actively fight against learning their tools, like this. It’s a nightmare. I don’t trust them. Don’t be that person.

Re: I Avoid Async/Await

#43

Post by chrisco255 »

SideburnsOfDoom wrote: post #20
moron4hire wrote: post #14

I try to read every one of these sorts of articles that comes up. I don't want to be caught flat-footed on some kind of weird memory leak issue from not using a pattern correctly, or something. But every single one of these articles that I've read against async/await has been nothing more than inventing "problems" to try to convince people to stick to raw promises strictly because that's what the author is comfortabl…

> you can't visually "see" that two await calls can be parallelized. Speak for yourself, buddy. Agreed. My first thought was to try var userSaveTask = save('userData', userData); var sessionSaveTask = save('session', sessionPrefences); await Task.WhenAll(userSaveTask, sessionSaveTask); I saw it before I got to the part of the text explaining how I wasn't going to just see it. > Furthermore, if we are to take advantag…

Yes, it is `await Promise.all()` in JS.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: I Avoid Async/Await

#44

Post by alerighi »

jonathanlydall wrote: post #40
zebracanevra wrote: post #7

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 a…

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…

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.

Re: I Avoid Async/Await

#45

Post by pawelmurias »

unityByFreedom wrote: post #30

I'll take "blog posts asserting silly things for clicks" for $100, Alex. All of this author's examples using .then() are single-line functions. Seems contrived to suit their opinion. Just use the right tool for the job.

Just typical medium garbage with constructed examples to claim that their artificial view point isn't that stupid.

Re: I Avoid Async/Await

#46

Post by beardedetim »

jonathanlydall wrote: post #40
zebracanevra wrote: post #7

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 a…

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…

.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.

Re: I Avoid Async/Await

#47

Post by kareemsabri »

The premise of this article seems flawed. We don't "code in a synchronous mindset" when we use async/await. I would expect most programmers are aware, after a 5 minute google search, that there is an asynchronous process happening and we need to ensure no execution after that line occurs until that process has resolved, hence we use await. If you know what it is doing, it's not complicated at all. It's identical to promise chaining but less ugly.

Re: I Avoid Async/Await

#48

Post by pausmfib »

I understand that the author is more familiar with the syntax of promises. Nonetheless, having a syntax similar to synchronous code allows developers to write more code remembering only the couple of changes in syntax instead of having to memorise a different one.

Re: I Avoid Async/Await

#49

Post by sidewndr46 »

zazibar wrote: post #39

Now maybe it’s just my familiarity with Promises, but I look at the third example and I can quickly see an opportunity. This entire article is built around the author's ignorance and could easily be summarised as "I avoid async/await syntax because I'm more familiar with promises". The author doesn't even appear to understand that async/await is syntactic sugar for promises.

I did not take me long to reach the same conclusion. The article can be summarized as "I am ignorant of the meaning of async/await, thus I don't use it". This is perhaps one incremental improvement from "I am ignorant of async/await, thus I use it poorly". But in the wrong direction.

Re: I Avoid Async/Await

#50

Post by vhakulinen »

wereHamster wrote: post #23
vhakulinen wrote: post #13

Regarding the error handling case, I've played around with the idea of implementing a Result type with typescript and hiding the errors behind that. The end result looks something like this const res = await getJSON('/thingy'); if (isErr(res)) { // Handle error. return; } You can read the details from here: https://thingsthatkeepmeupatnight.dev/posts/simple-typescrip...

Congrats, you've re-invented sumtypes!

Rather, copied over from other languages.
Post reply on HN