[zazibar]

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.

[sidewndr46]

I did not take me long to reach the same conclusion. The article can be summarized as "I am ignorant of the meaning of async/await, thus I don't use it". This is perhaps one incremental improvement from "I am ignorant of async/await, thus I use it poorly". But in the wrong direction.

[saimiam]

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.

[igemnace]

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 */]);

[jffry]

> How would you handle two asynchronous saves which can happen in parallel without using a Promise.all?

This question doesn't make sense. Async/await is just a nicer syntax for interacting with promises. So my answer to your "gotcha" question is just:

  await Promise.all([..., ...])

There's nothing impure going on here. The majority of the time, async/await can make it much easier to see a code's control flow by getting rid of most of the Promise related cruft and callbacks.

I would call Promise.all a benefit here, as it makes it stand out where I'm doing something in parallel.

[RedShift1]

  const x = somethingAsync();
  const y = somethingAsyncToo();

  return  { foo: await x, bar: await y }

There is no point in returning one before the other because you need both?

[jseban]

Promises are also just syntactic sugar to make your code look more synchronous, you can do everything with plain callbacks. Which I find ironic with the article that he argues against that but still just stops at the next turtle, instead of following his own advice and actually learning how Javascript and it's runtime works.

[mpalmer]

Not really correct.

    const fooP = fetch(a)
    const bar = await fetch(b)
    const foo = await fooP

[rwalle]

Wait, why don't do that? What's the point?

[bilater]

Yup - I prefer async/await but that was actually a good example on optimizing multiple promises I had not though of before.

[jrwr]

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.

[gorjusborg]

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.

[bdcravens]

It drove me crazy too, until I needed to use Puppeteer which requires you to write async/await (there are Puppeteer implementations in other languages, but they all seem to make compromises I didn't want). Generally speaking, async/await allows you to write code that looks and feels serial. Perhaps try using one of the async libraries for PHP to wrap your mind around the concept of async/await (like https://github.com/spatie/async)

[farmin]

Hyperscript can help with this. https://hyperscript.org/

Makes using a bit of JavaScript relatively simple, just not much in Stack Exchange yet which means reading docs..

[codeflo]

The author even implies in a footnote that switch statements are unusable. I mean, we probably all had painful experience with the “gotcha”, and I appreciate efforts towards safer designs. But I mean, let’s not be ridiculous. It works fine.

[snak]

Agreed, I stopped reading after this sentence.

[imtringued]

What the author wants is something like this:

    async {
        save()
        save()
    } catch (Exception e) {
        console.log("Handle error")
    }

async does not deliver this at all.

[_ZeD_]

what the author wants doesn't exists because the two saves will not actually run in parallel in any case. Not with `async save(); async save();` nor with `Promise.all` nor with any callback or any other means.

the author is conflating parallel with concurrent programming.

and in (the mono-thread world of) javascript the two calls will still occurs sequentially.

[gitfan86]

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