we need more compelling motivations/use cases
Closed this issue · 6 comments
What's the current stage of this proposal? Or better asking, what do we need to move this to the next step?
I would love to have this in the spec.
It's stage 1: https://github.com/tc39/notes/blob/8711614630f631cb51dfb803caa087bedfc051a3/meetings/2020-07/july-22.md#conclusionresolution-3
To advance to stage 2, we'd need much more compelling motivations and use cases. For example:
I don't think new syntax is warranted here. What these new operators would do is let you avoid typing Promise. something. That doesn't seem like it justifies the extra syntax. If we were to add more complex or combinatorial behavior, it would justify something more sophisticated than just omitting Promise.
There are a lot of issues here; I don't like the current proposed syntax. I could think of some await* that would come from Promise.all that could fetch things better. There are a lot of things I would like to keep discussing about this, but we don't have enough time during these meetings, and I would love if we could set this to Stage 1 to discuss it more.
I would like, for Stage 2 and beyond, this ergonomics point of people accidentally doing serial await, an area where this proposal would concretely improve, I would like to understand that better before Stage 2. That seems to be an empirical claim, I would like to see some examples. Right now the motivation is just "it would be nice to be able to do it". I want to understand better the ergonomics improvement.
etc.
Yes, we're lacking more compelling use cases for this. It should be either more powerful (like #9 proposed) or more useful (other than saving some characters).
I recently read an article about "why async-await is bad", one of the reasons is that: if you want to do the asynchronous tasks efficiently and correctly, you always have to deal with the underlying Promise itself. The author thinks it's some kind of abstraction leaking.
I think this proposal might help reduce the abstraction leaking because when you deal with multiple tasks, you don't have to Promise.all, but await.all. Maybe that's a possible motivation for this proposal.
That's part of my motivation, I think, just more clearly stated.
(If you're interested, the article I read is https://uniqname.medium.com/why-i-avoid-async-await-7be98014b73e )
I have updated the motivation of this proposal