[mrozbarry]

I prefer the raw promise syntax. It makes the promise chain look more like what it is, an asynchronous pipeline, and you don't need to litter async everywhere.

    const myAsyncThing = async (init) => {
      let value = await task1(init);
      value = await task2(value);
      return value;
    }

    const myPromiseThing = (init) => task1(init).then(task2)

I know this is a relatively simple and contrived example, but there are some times where async/await very much is bulky and gets in the way of just writing code.

[THBC]

That’s not ”raw Promise” syntax, that’s Thenable syntax.

Compare with

    const myPromise = new Promise((resolve, reject) => resolve(”foo”));
    

Afterwards either try-catch await myPromise, or use myPromise.then().catch()

[saurik]

I mean, you didn't even try :/.

    const myAsyncThing = async (init) => await task2(await task1(init))

This makes the promise chain look much more like what it is, given that the rest of the language uses nesting calls to indicate "after".

[mrozbarry]

I didn't write it like that because it obscures the call order. I wasn't trying to compare code line/count, just flow control and readability, which is certainly subjective.

[saurik]

If this "obscures the call order" then isn't that a problem with the programming language in general? If these functions weren't async, would you also not be willing to use g(f()), as that "obscures the call order"? (I certainly have met people who do.) If we aren't going to use function calls, and we also do not want to put these functions on separate lines as that is "bulky", then are we going to argue that we should have something similar to .then() for synchronous code?...

My argument here is that JavaScript is -- as well as most languages we use these days are -- fundamentally designed around the syntax of a function call, and so if you program in such for very long at all you get used to reading "inside out, right-to-left", as that's how function calls work. If we do not like inside out execution order, then we should fix the entire language (by using suffix notation... fwiw, I'd be totally on board ;P), rather than narrowly complain about it only in code which uses async/await and fixing it by abusing the OOP this argument exception to the ordering rule.

(I would also point out that the special syntax order exception you are relying on only works for a single argument, and so if you have to pass task2 both the result of task1 and a second argument to configure it, the usage of .then() breaks down unless we have a way to curry arguments, which we can always simulate using JavaScript's bind(), but at some point we are really going far out of our way to avoid coding using function calls, despite being in a language which relies on them everywhere else.)

At the end of the day, I am just looking for some consistency, so I can quickly and easily interpret what code does no matter whether it is synchronous or asynchronous and whether it takes zero, one, or more inputs.

[THBC]

    const value1 = await task1(init);
    const value2 = await task2(value1);