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

211–220 of 242 posts

Re: I Avoid Async/Await

#211

Post by chmod775 »

phendrenad2 wrote: post #199
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…

> 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 Sounds like you didn't understand the point of the article. Unfortunately, you're arguing against something the author never said, the author never said that async/await weren't promises. You just got stuck on the fact that the author used the term "promise" for the n…

> Sounds like you didn't understand the point of the article. Unfortunately, you're arguing against something the author never said, the author never said that async/await weren't promises.

Well. I never said that I didn't understand the article. Unfortunately you are arguing against something I never said. Funny how that works.

> The author is saying that non-async/await code is better code than async/await.

And what does "better" mean to the author?

The entire first section is devoted to the author talking about criteria such as "brittle"-ness, "error-prone"-ness, and "footguns".

You seem to be getting stuck up on the fact that the author never used the exact same wording as I did.

Re: I Avoid Async/Await

#212

Post by gitfan86 »

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.

There is a growing trend where people just memorize how to do things instead of understanding what those things actually do.

Re: I Avoid Async/Await

#213

Post by johnny22 »

BillyTheKing wrote: post #37

the whole blog-post seems a little constructed tbh - If I look at await doSomething(param) await doSomethingElse(param) the very first thing that comes to mind is that this can be very, very easily optimised by just doing await Promise.all([ doSomething(param), doSomethingElse(param) ]) This is something I come across literally every day - why exactly would that be an argument against async/await? much so on the cont…

Once you're sure the operation doesn't need to happen serially I hope :)

Re: I Avoid Async/Await

#214

Post by johnny22 »

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…

> Like how the author claims you can't visually "see" that two await calls can be parallelized.

I'm not gonna pretend to be a JS expert here, but isn't that exactly what you can see? Isn't that the whole point? It lets you easily take a second look and decide to check if the operations can happen in parallel or not.

I'm literally using 2 awaits in a row because android's BLE implementation doesn't necessarily like more than 1 operation happening at once, and I'm not doing enough other operations such that I need to implement a whole queue to handle it.

(although maybe the library i'm using should implement that queue)

Re: I Avoid Async/Await

#215

Post by MrJohz »

Kwantuum wrote: post #151
savanaly wrote: post #128

Earlier quoted context omitted.

This is absolutely correct why is it being downvoted lol

It really isn't, most native/standard APIs do not return Promises. Lots of things use callbacks. Being comfortable creating Promises from a callback-based API is definitely something any competent JS dev ought to be able to do.

A lot of APIs produce promises these days. The big one that I always need to promisify is `setTimeout`, but apart from that, I tend to find that if I'm using the `new Promise` API, I'm usually doing something wrong.

With Node APIs, there's a promisified version of pretty much everything. With browser APIs, there's usually a version with promises, and I'm struggling to think of an asynchronous API without promises that hasn't been superseded by something else (e.g. XMLHttpRequest -> fetch). If I'm converting from an event-emitter API to promises, there's usually going to be an impedance mismatch between the expectations of the event-based system and the promise-based system, and I probably need to explore another option.

I agree that any competent JS dev should understand how to create promises "from scratch" like this. But it still should probably be a fairly rare occurrence, and if I see a lot of `new Promise` calls in one place, it's pretty much always a sign that someone doesn't really understand how promises work.

Re: I Avoid Async/Await

#216

Post by recursivedoubts »

zkldi wrote: post #178
recursivedoubts wrote: post #80

I work on a web scripting language that abstracts away asyc/await: https://hyperscript.org/docs/#async we call it "Async Transparency" It lets you write code like this: fetch /some-url as json put the result's content into me where fetch is an async call, but you don't have to await it or anything or mark it as being an async fuction, whathaveyou effectively, we de-color the language: https://journal.stuffwithstuff.c…

How would you allow running the fetches in fetch /some-url as json fetch /some-other-url as json do_stuff_with(result1, result2) in parallel?

hyperscript is focused on the common cases for light front end scripting, so right now there isn't syntax for doing operations in parallel.

If I needed that I would kick out to javascript and use Promise.all() to return an expression that hyperscript could then sync on

the wheelhouse for hyperscript is stuff like:

  on load
    wait 5s
    transition my opacity to 0
    remove me
where you don't have to do any async or callback stuff for what are, at root, async operations.

Re: I Avoid Async/Await

#217

Post by oaiey »

robmccoll wrote: post #84

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…

I actually start to appreciate function coloring in C# to never forget that I am operating on asynchronous code. In .NET the compiler also throws warnings if you do not await or pickup the task/promise.

I also believe that you should see where asynchronous behavior can happen in your code. So from that angle i also appreciate the keyword and the coloring. Hidden resource access is pure evil.

Re: I Avoid Async/Await

#218

Post by eurasiantiger »

wiml wrote: post #131
eurasiantiger wrote: post #124

Earlier quoted context omitted.

I have seen plenty of (usually junior front-end) devs resort to exactly this kind of cargo cult coding and magical thinking.

Well, they're junior devs. You're supposed to help them get past that stage, not just throw away all your tools.

What made you think I haven’t been helping them?

Re: I Avoid Async/Await

#219

Post by eurasiantiger »

deschutes wrote: post #155
joe_guy wrote: post #133

Earlier quoted context omitted.

There's no merit of what should be a project wide function being a single line instead of 3 to avoid "hard to grok" syntax.

Wait till you see the rest of javascript...

Your comment is snarky and categorically dismissive. Care to explain why you have taken such an aggressive stance against JS?

Re: I Avoid Async/Await

#220

Post by kabes »

adamauckland wrote: post #152
kabes wrote: post #142

Earlier quoted context omitted.

I agree but second one could just be `() => Promise.resolve()`

It could, but depending on how you use it, you're changing scoping.

True. But these days it's rare to see a scope other than what you'd expect from the short hand version. Old school JS with plain prototypes and flexible 'this' scope is very powerful, but is too hard to understand and thus rare these days.
Post reply on HN