4 ms·

Yeah I had an argument on here about callbacks vs. Promises. I’m pretty convinced the ones making the pro callbacks arguments have never actually used JavaScrip

by dimgl 4y ago

Yeah I had an argument on here about callbacks vs. Promises. I’m pretty convinced the ones making the pro callbacks arguments have never actually used JavaScript in a professional capacity, especially in large codebases. I thought the callbacks vs Promises using `async/await` debate was settled.

ericlewis 4y ago
I’ve never heard anyone argue for callbacks. But the async/await problem isn’t entirely dead since folks still argue generators should be doing they job. They’re similar flavors of cooperative multitasking I guess. But callbacks.. they’re really hard to test without abusing entirely different parts of js. Not that promises are much better.
- klabb3 4y ago
  Yes, but async await isn't really complete without good support for streaming ops and APIs that support them first class. That includes merging streams, canceling them, etc (kinda like Rx). It probably needs both push and pull streams as well. We're not there yet, so in the meantime we have to use events and event listeners, in addition to async/await. I think that's perfectly fine.
  - michaelsbradley 4y ago
    Have you tried Ix as a complement to Rx? https://github.com/ReactiveX/IxJS https://github.com/ReactiveX/IxJS
    - klabb3 4y ago
      No I have not, I prefer to go lightweight so good old event listeners are perfectly fine for my purposes. But once you have ubiquitous first class support for async iterables and so on I'm all aboard. I see Rx very much like an experiment that should influence language features and std libs, rather than a standalone framework.
nameisname 4y ago
I couldn't agree more and I've been in this same situation. When your codebase is hundreds of thousands of lines of JavaScript suddenly promises with async await make a lot of sense.
- BiteCode_dev 4y ago
  Await is nice, but even with promises, I'd settle with people using them correcly: return something in the promise to the next one can use it without nesting. But people use promises... and keep nesting.
  - somishere 4y ago
    I'd argue (from memory!) that there are solid edge cases for nesting promises .. probably all scope-related, where multiple async operations are required for a result that would otherwise require scope-leak / pollution.
  - Jach 4y ago
    Even back in early Node days we figured this out with ideas/libs like async.waterfall, which let you turn nesting into a serial flow: async.waterfall([function(callback) { callback(null, 'one', 'two'); }, function(arg1, arg2, callback) { callback(null, 'three'); }, function(arg1, callback) { callback(null, 'done'); }]); Thus you don't need to make things like 'one' and 'two' into scoped variables that require nesting the second function into the first one so it can see them, and you can split those functions out of being inline lambdas. Or early Promise libs like coolaj86's futures which included a sequence, letting you do the same sort of thing: var seq = Futures.sequence(); seq .then(function(next) { setupContextObj(next, obj)}) .then(retrieveMD) ... .then(postUrlDataToS3) ... while also being able to make nice little future() objects you could return from functions and pass around. To be fair it's still JS and lots of third party code needed regular old callbacks so it was still easy to get excessive levels of nesting of various things that leave you with function-closing sequences like });}});return future;} or });}}).end(buf);} that could make a Lisper blush. These days it's quite a bit nicer having native Promises, a better community-wide understanding of how to use them, but also the syntactic sugar of async/await improves over the waterfall/sequence/.then&.catch chaining styles (especially when it comes to modifications where you want to use data from previous stages of the chain in later stages).

by dimgl 4y ago

ericlewis 4y ago

I’ve never heard anyone argue for callbacks. But the async/await problem isn’t entirely dead since folks still argue generators should be doing they job. They’re similar flavors of cooperative multitasking I guess. But callbacks.. they’re really hard to test without abusing entirely different parts of js. Not that promises are much better.

klabb3 4y ago
Yes, but async await isn't really complete without good support for streaming ops and APIs that support them first class. That includes merging streams, canceling them, etc (kinda like Rx). It probably needs both push and pull streams as well. We're not there yet, so in the meantime we have to use events and event listeners, in addition to async/await. I think that's perfectly fine.
- michaelsbradley 4y ago
  Have you tried Ix as a complement to Rx? https://github.com/ReactiveX/IxJS https://github.com/ReactiveX/IxJS
  - klabb3 4y ago
    No I have not, I prefer to go lightweight so good old event listeners are perfectly fine for my purposes. But once you have ubiquitous first class support for async iterables and so on I'm all aboard. I see Rx very much like an experiment that should influence language features and std libs, rather than a standalone framework.

nameisname 4y ago

I couldn't agree more and I've been in this same situation. When your codebase is hundreds of thousands of lines of JavaScript suddenly promises with async await make a lot of sense.

BiteCode_dev 4y ago
Await is nice, but even with promises, I'd settle with people using them correcly: return something in the promise to the next one can use it without nesting. But people use promises... and keep nesting.
- somishere 4y ago
  I'd argue (from memory!) that there are solid edge cases for nesting promises .. probably all scope-related, where multiple async operations are required for a result that would otherwise require scope-leak / pollution.
- Jach 4y ago
  Even back in early Node days we figured this out with ideas/libs like async.waterfall, which let you turn nesting into a serial flow: async.waterfall([function(callback) { callback(null, 'one', 'two'); }, function(arg1, arg2, callback) { callback(null, 'three'); }, function(arg1, callback) { callback(null, 'done'); }]); Thus you don't need to make things like 'one' and 'two' into scoped variables that require nesting the second function into the first one so it can see them, and you can split those functions out of being inline lambdas. Or early Promise libs like coolaj86's futures which included a sequence, letting you do the same sort of thing: var seq = Futures.sequence(); seq .then(function(next) { setupContextObj(next, obj)}) .then(retrieveMD) ... .then(postUrlDataToS3) ... while also being able to make nice little future() objects you could return from functions and pass around. To be fair it's still JS and lots of third party code needed regular old callbacks so it was still easy to get excessive levels of nesting of various things that leave you with function-closing sequences like });}});return future;} or });}}).end(buf);} that could make a Lisper blush. These days it's quite a bit nicer having native Promises, a better community-wide understanding of how to use them, but also the syntactic sugar of async/await improves over the waterfall/sequence/.then&.catch chaining styles (especially when it comes to modifications where you want to use data from previous stages of the chain in later stages).