4 ms·

Well, I was happy using normal callbacks, but then promises made me a bit happier and now I even happier with async/await. You can definitely write clean code

by kolme 10y ago

Well, I was happy using normal callbacks, but then promises made me a bit happier and now I even happier with async/await. You can definitely write clean code with only callbacks, but one has to be pretty careful if there are many nested asynchronous actions. Promises and await make that code very much clearer.

joshuahutt 10y ago
Also, if you're trying to do something after multiple async operations, you've got to manually count your callbacks. (As opposed to using Promise.all)
- elmigranto 10y ago
  No. You use flow management library. Just how you don't manually execute multiple promises with `Array.forEach` and same manual counting. Latter just happens to be in stdlib while former is userland.
  - euroclydon 10y ago
    Please give an example of a flow mgmt lib.
    - elmigranto 10y ago
      Probably the most popular one is `async` — http://caolan.github.io/async/ http://caolan.github.io/async/.
    - tkxxx7 10y ago
      I really enjoy this one - https://github.com/bigeasy/cadence https://github.com/bigeasy/cadence
shados 10y ago
And then as you use promise based code more and more (including with async/await), you eventually come to realize that while it looked good at first, its deeply, deeply flawed, and is at best a stepping stone to Observables :)
- egeozcan 10y ago
  An observable is semantically very different to a promise, even if it can be thought as a promise with subsequent success calls. Here is the proposal: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable
  - shados 10y ago
    Your point being? The semantic is different, but everything a promise can do, an observable can do (with roughly the same amount of code), but the other way around isn't true. Observables are just better in basically every ways. Real world implementations also have proper error handling and decent APIs to handle aborting -today-, while the TC39 is still jumping back and forth trying to figure out how to handle it in promises so that Fetch can stop being useless.

by kolme 10y ago

joshuahutt 10y ago

Also, if you're trying to do something after multiple async operations, you've got to manually count your callbacks. (As opposed to using Promise.all)

elmigranto 10y ago
No. You use flow management library. Just how you don't manually execute multiple promises with `Array.forEach` and same manual counting. Latter just happens to be in stdlib while former is userland.
- euroclydon 10y ago
  Please give an example of a flow mgmt lib.
  - elmigranto 10y ago
    Probably the most popular one is `async` — http://caolan.github.io/async/ http://caolan.github.io/async/.
  - tkxxx7 10y ago
    I really enjoy this one - https://github.com/bigeasy/cadence https://github.com/bigeasy/cadence

shados 10y ago

And then as you use promise based code more and more (including with async/await), you eventually come to realize that while it looked good at first, its deeply, deeply flawed, and is at best a stepping stone to Observables :)

egeozcan 10y ago
An observable is semantically very different to a promise, even if it can be thought as a promise with subsequent success calls. Here is the proposal: https://github.com/tc39/proposal-observable https://github.com/tc39/proposal-observable
- shados 10y ago
  Your point being? The semantic is different, but everything a promise can do, an observable can do (with roughly the same amount of code), but the other way around isn't true. Observables are just better in basically every ways. Real world implementations also have proper error handling and decent APIs to handle aborting -today-, while the TC39 is still jumping back and forth trying to figure out how to handle it in promises so that Fetch can stop being useless.