Comment by matharmin | Hacker News Reader

Comment by matharmin | Hacker News Reader

Parent Full thread

De-facto doesn't mean it's the only option, it means it's the dominant option, and that is true.

Promises don't have a built-in way to cancel chains (neither do plain callbacks), and I think that was the right decision. AbortController is becoming a common pattern, and that is working quite well in my opinion.

Promises are not purely stylistic. It gives you guarantees, such as that each Promise can only resolve or reject once. It can easily be used in utility functions such as Promise.all and Promise.race. There are libraries that have equivalents for callback-style APIs, but it's typically more tricky to use, and relies on specific conventions being followed.

NodeJS took a while to adopt it, but all Node APIs I use now have Promise versions. All/most Deno APIs use Promises. All new browser APIs use Promises, and for the existing callback-style ones such as IndexedDB, most developers use Promise wrapper libs to make it manageable.

Of course you're free to use callbacks of you want to. But I would definitely recommend Promises and async/await to any new developer, make it a requirement on any team I lead, and even question why someone uses callbacks in their code if I interview them.

Very well said.

Complementing your answer, I'd also like to point out that another notable guarantee that promises give us is that their continuations are never executed synchronously (even when they could), which prevents the problem described by https://blog.izs.me/2013/08/designing-apis-for-asynchrony/.

Promises don't have a built-in way to cancel chains (neither do plain callbacks)

That is a false comparison. A function is not comparable to a promise chain. A chain of callbacks can be cancelled by simply returning early in one callback instead of calling or responding to a forthcoming additional event.

Not all Node APIs have promise methods regardless of the few you use personally. This sounds more like people trying to impose their vanity opinions. The mentality of: It sometimes works for me, so other people are wrong if they don't do it the way that matches my preferences.

and even question why someone uses callbacks in their code if I interview them.

Why would you pose the question if you already biased against the answer? Is this an attempt to prejudice a candidate?

> Why would you pose the question if you already biased against the answer?

Why would you pose _this_ question if you are already biased against the answer? :)

But to answer your question:

1. to question your own bias. You might get an answer you didn't expect that actually helps you gain new insight.

2. to inform the candidate that good reasons are needed to keep their style if they want to work for you. "I prefer my own style because I'm used to it" creates single points of failure, while "I prefer this style because of X" improves code quality.

I see what you mean about promise chain cancellation, I misunderstood that part. You can still structure Promises using nesting instead of chains to get the same effect as with callbacks, but in reality I just use async/await instead.

> Why would you pose the question if you already biased against the answer? Is this an attempt to prejudice a candidate?

By question I mean I may judge the candidate for it. Of course it's your choice if you prefer callbacks, but I'd view that as a potential compatibility issue with my team.

Reply on news.ycombinator.com