Cory
2 min readApr 14, 2022

--

Forgive me if I fanboy out a little here. I have to say that you have significantly influenced my in my career over the years. Thank you for all the fantastic content you put out, particularly around functional style javascript. It's a super big honor to have you engage with me.

With that said, may I quibble somewhat 😬?

I think I agree with your assertion in point No.1. Or at least it is certain a valid point. But I make a distinction between utilities and "business logic" code. the `asyncPipe` utility could be implemented with promises or async/await and the consumer would have the exact same API. The intent is to abstract over the implementation making what implementation one uses largely irrelevant.

But I have to disagree with point No.2. I don't find `f(await y)` easier to read than `y.then(f)`. I think this falls into a familiarity bias fallacy to some extent (though perhaps I'm the one experiencing the bias?).

It was not my intent to suggest that async/await is an anti-pattern, or not even that we collectively should avoid async/await -- though perhaps I did a poor job of conveying that given so many strong reactions to this post. But it is something that <i>I</i> tend to avoid. Async/await tends to be awkward in the style of JavaScript I tend to write, whereas taking advantage of the "Functorishness" of Promises is much more natural. I didn't want this article to go into the weeds on functional style, but in hind-sight perhaps that was a mistake. It seems that without that angle, my arguments were more evocative than persuasive. Either way, I am overjoyed that you took the time to respond. Thank you again for all your contributions. I routinely point newer devs to you and your articles when they ask for recommendations.

--

--

Cory
Cory

Written by Cory

Front End Engineer with deep technical expertise in JS, CSS, React, Frontend Architecture, and lots more. I lean functional, but I focus on maintainability.

Responses (1)