3 ms·

Currently, promises are the de-facto way of handling asynchronous tasks in Javascript Not really. Most of the Node API is still reliant upon callbacks and the

Currently, promises are the de-facto way of handling asynchronous tasks in Javascript Not really. Most of the Node API is still reliant upon callbacks and the frontend absolutely doesn’t care. With one technical exception[1] the use of promises is purely stylistic. As someone old I still prefer callbacks because it’s just functions. One of the biggest frustrations with JavaScript is people attempting to impose their opinions on you. If you prefer promises then just use promises. The language provides 3 options for asynchronous handling and doesn’t care what path you take. [1] A promise chain cannot be cancelled or exited early without a throw.

pavlov 3y ago
Promises are now enshrined in the language syntax through the async / await keywords, so I would say they're increasingly unavoidable.
beeboobaa 3y ago
> The language provides 3 options for asynchronous handling and doesn’t care what path you take. The language actually just provides one: async/await.
- austin-cheney 3y ago
  callbacks, promises, async/await. That is 3.
  - beeboobaa 3y ago
    Callbacks are just functions, promises are part of a standard library (not the language), only async/await is part of the language itself.
    - lucideer 3y ago
      Promises are part of the language. Async/await are just syntax around Promises - they're all 1 feature.
      - anamexis 3y ago
        Technically, await isn't specific to promises. It works with any then-able object.
        culi 3y ago
        What are other then-able objects besides Promises?
        anamexis 3y ago
        { then: (callback) => callback("foo") } Anything that has the same signature as a Promise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise#thenables https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
        culi 3y ago
        Okay, but nothing built in to the standard. In fact, even the docs you linked only point out that other implementations of Promises are "then-able". I guess I was under the impression that there were other, non-Promise, examples of thenables
        lucideer 3y ago
        The main use I've seen is returning "promise-like" objects in functions that can be sync or async depending on params but are expected to have a common return type.
      - culi 3y ago
        To add to this, async/await is not a complete replacement. As in, it doesn't mean you'll never have to write `Promise` in your code. You still have to rely on Promise.all when you want to run multiple promises concurrently instead of sequentially
- lucideer 3y ago
  The language provides Promise objects[0]. Async/await is just syntactic sugar around Promises - every await awaits a Promise object, every async returns one. Also, it's a bit weird to say callbacks -vs- promises. Callbacks aren't inherently async in themselves; there are some native async APIs that accept callbacks - the callbacks themselves are just functions, its the native APIs that are async. Also, Promises take and execute callbacks. We're still using callbacks. What Promise objects did (for the first time) was give programmers the power to implement async functionality in the native language themselves, outside of native API calls to external functionality. [0] https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-objects https://tc39.es/ecma262/multipage/control-abstraction-object...
  - austin-cheney 3y ago
    Differences between promises and callbacks is not the concern here. There are three options for asynchronous handling whether or not they are different under the hood and regardless if this is all just vanity. What Promise objects did Callbacks already did that. Its just moving one concern from an API to a method. Nonetheless the capability was already there natively in the language, which is called the event loop. In all things, even outside of code, people express vanity as an implicit means of advertising some manner of their identity or preferences. To the contrary people impose vanity on others only as a means of compensating for their own low confidence. Confidence is generally exceptionally low in software.
lucideer 3y ago
> As someone old I still prefer callbacks That's perfectly fair but you may be in a bubble if you really believe your preference reflects the general tendency of the community. Yes, a lot of Node's API is still reliant upon callbacks, but newer APIs where promise support has been added are generally preferred, and outside of those, most people rely on library abstractions anyway - most of which wrap Node's internal APIs in promises. Bluebird was around since 2013 & was very popular with the NodeJS community. > it’s just functions So are promises really. There's very little effective syntactic difference between `const x = new Promise((func, func) => {});` and a function accepting callback(s) - the main differentiator is a separate error callback instead of the error-first argument convention. Yes the internals are different to allow assignment & chaining without nesting but nesting is still just as possible if preferred. But yeah if you prefer callbacks go ahead. Just make sure the team you're collaborating with is reasonably aligned on preference.
- austin-cheney 3y ago
  are generally preferred Who cares? Why are you trying to tell me what my opinion on code preference is? https://owl.excelsior.edu/argument-and-critical-thinking/logical-fallacies/logical-fallacies-bandwagon/ https://owl.excelsior.edu/argument-and-critical-thinking/log... So are promises really Absolutely not. Promises are a separate convention of chained .then methods.
  - lucideer 3y ago
    > Who cares? You seemed to as you commented to that effect. > Why are you trying to tell me what my opinion on code preference is? Did I?
  - nonethewiser 3y ago
    > are generally preferred > Who cares? You said “Not really” in response to the claim that “Currently, promises are the de-facto way of handling asynchronous tasks in Javascript.” So I guess you care.
    - 3y ago
dimgl 3y ago
> Most of the Node API is still reliant upon callbacks and the frontend absolutely doesn’t care. This is not true at all. Promises and async/await are ubiquitous.
- austin-cheney 3y ago
  In Node promises require separate methods. Promise methods do not exist for all the Node APIs at this time. * Library with/without promises - https://nodejs.org/dist/latest-v21.x/docs/api/fs.html https://nodejs.org/dist/latest-v21.x/docs/api/fs.html * Library without promises - https://nodejs.org/dist/latest-v21.x/docs/api/net.html https://nodejs.org/dist/latest-v21.x/docs/api/net.html
  - dimgl 3y ago
    I understand that some parts of the Node.js API does not use promises. I'm saying that promises are ubiquitous in Node.js codebases. The original comment said that promises are "not really" used in Node.js codebases. This is blatantly false. Most, if not all Node.js codebases I've worked with all use promises. And if they still use callbacks... you better believe I'm moving them to promises :) Promises are not hard at all. I'm surprised there's such a pushback. I've been using async/await since like 2018.
    - austin-cheney 3y ago
      That is not what the original comment said. The original comment said: Not really. Most of the Node API is still reliant upon callbacks and the frontend absolutely doesn’t care.
matharmin 3y ago
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.
- austin-cheney 3y ago
  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?
  - moring 3y ago
    > 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.
deleted 3y ago
[deleted]
bastawhiz 3y ago
> A promise chain cannot be cancelled or exited early without a throw. > .then(() => new Promise(() => {})) A promise that never resolves is effectively an abort.

pavlov 3y ago

Promises are now enshrined in the language syntax through the async / await keywords, so I would say they're increasingly unavoidable.

beeboobaa 3y ago

> The language provides 3 options for asynchronous handling and doesn’t care what path you take. The language actually just provides one: async/await.

austin-cheney 3y ago
callbacks, promises, async/await. That is 3.
- beeboobaa 3y ago
  Callbacks are just functions, promises are part of a standard library (not the language), only async/await is part of the language itself.
  - lucideer 3y ago
    Promises are part of the language. Async/await are just syntax around Promises - they're all 1 feature.
    - anamexis 3y ago
      Technically, await isn't specific to promises. It works with any then-able object.
      - culi 3y ago
        What are other then-able objects besides Promises?
        anamexis 3y ago
        { then: (callback) => callback("foo") } Anything that has the same signature as a Promise. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise#thenables https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
        culi 3y ago
        Okay, but nothing built in to the standard. In fact, even the docs you linked only point out that other implementations of Promises are "then-able". I guess I was under the impression that there were other, non-Promise, examples of thenables
        lucideer 3y ago
        The main use I've seen is returning "promise-like" objects in functions that can be sync or async depending on params but are expected to have a common return type.
    - culi 3y ago
      To add to this, async/await is not a complete replacement. As in, it doesn't mean you'll never have to write `Promise` in your code. You still have to rely on Promise.all when you want to run multiple promises concurrently instead of sequentially
lucideer 3y ago
The language provides Promise objects[0]. Async/await is just syntactic sugar around Promises - every await awaits a Promise object, every async returns one. Also, it's a bit weird to say callbacks -vs- promises. Callbacks aren't inherently async in themselves; there are some native async APIs that accept callbacks - the callbacks themselves are just functions, its the native APIs that are async. Also, Promises take and execute callbacks. We're still using callbacks. What Promise objects did (for the first time) was give programmers the power to implement async functionality in the native language themselves, outside of native API calls to external functionality. [0] https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-objects https://tc39.es/ecma262/multipage/control-abstraction-object...
- austin-cheney 3y ago
  Differences between promises and callbacks is not the concern here. There are three options for asynchronous handling whether or not they are different under the hood and regardless if this is all just vanity. What Promise objects did Callbacks already did that. Its just moving one concern from an API to a method. Nonetheless the capability was already there natively in the language, which is called the event loop. In all things, even outside of code, people express vanity as an implicit means of advertising some manner of their identity or preferences. To the contrary people impose vanity on others only as a means of compensating for their own low confidence. Confidence is generally exceptionally low in software.

lucideer 3y ago

> As someone old I still prefer callbacks That's perfectly fair but you may be in a bubble if you really believe your preference reflects the general tendency of the community. Yes, a lot of Node's API is still reliant upon callbacks, but newer APIs where promise support has been added are generally preferred, and outside of those, most people rely on library abstractions anyway - most of which wrap Node's internal APIs in promises. Bluebird was around since 2013 & was very popular with the NodeJS community. > it’s just functions So are promises really. There's very little effective syntactic difference between `const x = new Promise((func, func) => {});` and a function accepting callback(s) - the main differentiator is a separate error callback instead of the error-first argument convention. Yes the internals are different to allow assignment & chaining without nesting but nesting is still just as possible if preferred. But yeah if you prefer callbacks go ahead. Just make sure the team you're collaborating with is reasonably aligned on preference.

austin-cheney 3y ago
are generally preferred Who cares? Why are you trying to tell me what my opinion on code preference is? https://owl.excelsior.edu/argument-and-critical-thinking/logical-fallacies/logical-fallacies-bandwagon/ https://owl.excelsior.edu/argument-and-critical-thinking/log... So are promises really Absolutely not. Promises are a separate convention of chained .then methods.
- lucideer 3y ago
  > Who cares? You seemed to as you commented to that effect. > Why are you trying to tell me what my opinion on code preference is? Did I?
- nonethewiser 3y ago
  > are generally preferred > Who cares? You said “Not really” in response to the claim that “Currently, promises are the de-facto way of handling asynchronous tasks in Javascript.” So I guess you care.
  - 3y ago

dimgl 3y ago

> Most of the Node API is still reliant upon callbacks and the frontend absolutely doesn’t care. This is not true at all. Promises and async/await are ubiquitous.

austin-cheney 3y ago
In Node promises require separate methods. Promise methods do not exist for all the Node APIs at this time. * Library with/without promises - https://nodejs.org/dist/latest-v21.x/docs/api/fs.html https://nodejs.org/dist/latest-v21.x/docs/api/fs.html * Library without promises - https://nodejs.org/dist/latest-v21.x/docs/api/net.html https://nodejs.org/dist/latest-v21.x/docs/api/net.html
- dimgl 3y ago
  I understand that some parts of the Node.js API does not use promises. I'm saying that promises are ubiquitous in Node.js codebases. The original comment said that promises are "not really" used in Node.js codebases. This is blatantly false. Most, if not all Node.js codebases I've worked with all use promises. And if they still use callbacks... you better believe I'm moving them to promises :) Promises are not hard at all. I'm surprised there's such a pushback. I've been using async/await since like 2018.
  - austin-cheney 3y ago
    That is not what the original comment said. The original comment said: Not really. Most of the Node API is still reliant upon callbacks and the frontend absolutely doesn’t care.

matharmin 3y ago

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.

austin-cheney 3y ago
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?
- moring 3y ago
  > 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.

deleted 3y ago

[deleted]

bastawhiz 3y ago

> A promise chain cannot be cancelled or exited early without a throw. > .then(() => new Promise(() => {})) A promise that never resolves is effectively an abort.