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 comfortable with using. No actually technical merits are discussed. Just fantasy issues so author can feel superior for not learning something new.
Like how the author claims you can't visually "see" that two await calls can be parallelized. Speak for yourself, buddy. And then complains about "having to go back to using promises" to affect the parallelization. My dude, it was promises all along.
It's just syntax. Use it, don't use it, mix and match it. It's not a moral issue.
> 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 advantage of parallelization in the async/await example, we must use promises anyway.
Again, Speak for yourself, buddy. "await Task.WhenAll" does that job in c#, and there must be a JavaScript equivalent.
IDK, this may be the c# mindset. yes, "async / await" is an extra-ordinarily complex feature that can easily be done wrong. But its also very useful and powerful, so lets not throw it out.
> 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)
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 comfortable with using. No actually technical merits are discussed. Just fantasy issues so author can feel superior for not learning something new.
Like how the author claims you can't visually "see" that two await calls can be parallelized. Speak for yourself, buddy. And then complains about "having to go back to using promises" to affect the parallelization. My dude, it was promises all along.
It's just syntax. Use it, don't use it, mix and match it. It's not a moral issue.