Async/await was the latest buzzword a few years back, but it never had any substance. A lot of inexperienced programmers thought it was the greatest thing ever. Unfortunately, they were overly focusing on the look of the code, and not the true readability or usability of the code. Async/await certainly makes you code "look" synchronous, but it's just shuffling the complexity around. The complexity is still there, and you will have to think about it.
I Avoid Async/Await
201–210 of 242 posts
Re: I Avoid Async/Await
#202JavaScript Promises have their issues - the same ones all asynchrony-providing libraries do. I feel the author takes a hard stance on something quite nuanced.
Syntactic sugar hides the API, making it more ergonomic, also leaking those problems. Same problem, different API
Re: I Avoid Async/Await
#203Earlier quoted context omitted.
I didn’t read the article like that at all. How would you handle two asynchronous saves which can happen in parallel without using a Promise.all? Don’t think you can…and that’s pretty much the entire point of the article. Async/await is useless unless you are willing to serialize your calls defeating the entire point of async code.
Just because you use async/await doesn't mean you can't use Promise.all. In fact, my immediate intuition with the await examples was to parallelize with Promise.all. await Promise.all([/* build promises */]);
Yeah they had that in the post.
Re: I Avoid Async/Await
#204Earlier quoted context omitted.
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?
The whole async/await paradigm (including promises) is trying to fit square pegs into round holes (trying to make async processes look like they are synchronous). Just look at the comments on this page; even though async/await/promises have been around for years they are still causing difficulties for even the most experienced devs. It doesn't mean it can't be mastered, it can, but the whole paradigm is so fraught wi…
> simple thenable object
Wouldn't you simply be reinventing promises?
Re: I Avoid Async/Await
#205Earlier 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.
> I've never seen someone who understands promises or async await do that. You'd have to know nothing about what the async keyword actually does to be compelled to do that. > usually junior front-end So you agree with each other then?
Good day, axe handle.
Re: I Avoid Async/Await
#206Now 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 didn’t read the article like that at all. How would you handle two asynchronous saves which can happen in parallel without using a Promise.all? Don’t think you can…and that’s pretty much the entire point of the article. Async/await is useless unless you are willing to serialize your calls defeating the entire point of async code.
Wait, why don't do that? What's the point?
Re: I Avoid Async/Await
#207Earlier quoted context omitted.
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?
The whole async/await paradigm (including promises) is trying to fit square pegs into round holes (trying to make async processes look like they are synchronous). Just look at the comments on this page; even though async/await/promises have been around for years they are still causing difficulties for even the most experienced devs. It doesn't mean it can't be mastered, it can, but the whole paradigm is so fraught wi…
> trying to make async processes look like they are synchronous
That is NOT what async/await is about — after all, async explicitly marks functions as asynchronous. Not exactly trying to hide that.
Async/await is syntactic sugar. It is there to make working with Promises less verbose.
That is almost all: await pauses current function execution in the main event loop, which is an important detail
Re: I Avoid Async/Await
#208Earlier quoted context omitted.
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.
I felt the same way coming from a threaded language. Learning the event loop, then promises, then async/await is a must. Today, you probably should throw typescript on top. A steep learning curve just to get back to a typed language that can do things concurrently. You do get used to it, but it is a mess of stuff.
This is ridiculous. Handling real threads is much more complicated than handling async calls and the event loop of JavaScript.
Re: I Avoid Async/Await
#209First 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…
> The point of async/await is not to never have the word "Promise" appear in your code.
Indeed it is not the point, and in that sense your criticism of the article is correct.
However, there are people who argue[1] that it is, in fact, a good thing to never have the word "Promise" appear in your code, that not having the freedom to execute whatever code you want after launching an asynchronous operation and instead having the predictability of always returning to the scheduler makes reasoning about asynchronous code much simpler. (For one thing, you can now reliably think—and have syntactic support for thinking—in terms of sequential coroutines with predictable yield points and known parents.)
In the context that Smith refers to (trio vs asyncio in Python, regarding which also see the first, more Python-specific but IMO better-argued post[2]) my experience actually bears that out. How well this works given the historical API baggage in JavaScript, I don’t know, but probably not very well.
Another curious thing is that the line of research JavaScript promises originate from[3] (Mark Miller co-wrote the spec proposal IIRC) does not use them as the user interface; instead, using the "eventual send"[4], you queue up method calls to objects (which can be promised results of other queued calls, and you may pass other promised objects as arguments).
I cannot clearly articulate the relation of this to Smith’s notion of “structured concurrency” (I wish I could), but in any case it contributes some more weight to the opinion that the ergonomics of Promises are indeed subpar. It might well be, though, that in the context of JavaScript you can’t actually enforce enough structure on the preexisting APIs to build a superior alternative.
[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[2] https://vorpus.org/blog/some-thoughts-on-asynchronous-api-de...
Re: I Avoid Async/Await
#210Earlier quoted context omitted.
But in JavaScript, these two awaits will not happen in parallel, you really need to await Promise.all() for that.
In Javascript, a Promise is started as soon as it is created. In other words, this is not the `await` that starts the Promise. If the first await is the slowest, the second one will return immediately (like calling .then on an already resolved promise).
+1 Notably, this is different in Python where promises (futures) are executed lazily, i.e. when you await them.