I stopped reading after the author made it clear they do not understand async/await is merely syntactic sugar for Promises.
Depends on the language. In C# they most definately not only syntactic sugar.
I Avoid Async/Await
51–60 of 242 posts
Re: I Avoid Async/Await
#52> The keywords async and await should give us the same intuition that the then does in the third. But I’ll wager for many engineers it doesn’t.
It does.
Re: I Avoid Async/Await
#53Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admit is a bit of a nuisance workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.
By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).
Re: I Avoid Async/Await
#54I never liked promises when they were first introduced because I never perceived this "callback hell" to be an unmanageable problem; there are excellent libraries to manage callback composition, e.g. https://caolan.github.io/async/v3/ When Promises came along I didn't feel they added much value; in fact it made things more complicated (new paradigm, harder to compose). Still, I went with it because everyone else went…
[deleted]
Re: I Avoid Async/Await
#55I was really hoping this article would discuss the benefits of using raw generators over async/await.
By using async/await, we are inherently limited by the flow control because we are forced into await resolving promises.
This is why libraries like redux-saga[0] or cofx[1] use generators.
https://redux-saga.js.org https://github.com/neurosnap/cofx
Generators provide much better flexibility over flow control and allow us to treat side effects as data.
Re: I Avoid Async/Await
#56If 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.
Re: I Avoid Async/Await
#57Now 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 avoid Javascript outright because async/await/promise is confusing to me. I blame it on being a PHP Programmer and likes things to run serially.
Re: I Avoid Async/Await
#58I don't find the first example convincing at all - to me await clearly indicates you are going to be blocking until the result arrives.
Re: I Avoid Async/Await
#59As a fullstack dev, I worked with - Spring MVC (Java Futures) - Spring Webflux (Reactor observables) - Scala (Scala Futures & for comprehensions) - TS async/await - Angular observables - React hooks (which combined with Redux, React Query etc. is a special approach to async programming.) I think it's very important to understand that ultimately, async (non-blocking) programming is kind of a "hard problem" and there i…
You can't talk about async await without talking about try, catch, and finally.
I don't think async+await+try+catch+finally is simpler than promises in any way.
I don't find anything simple or clean about imperative error handling.
Re: I Avoid Async/Await
#60I like big promises and I cannot lie?