It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data flow. Instruction scheduling is an explicit sequence with callbacks (well, assuming the API calls you back precisely once), but scheduling is an implicit topological sort of the directed acyclic dependency graph of promises.

Sometimes, when it comes to side effects, implicit scheduling is less than ideal. You need specific things to happen in a specific order. The solution is to introduce data dependencies to force a particular schedule. This is precisely what is done by monads in Haskell. However, unlike Haskell, JavaScript doesn't have "do" syntax, so there's no convenient notation for a nested chain of bindings.

The result of not having monadic binding syntax is that you wind up with some funky nested chain of getY(x).then(y => y.then(z => z.then(.... OR you have to declare variables up top, flatten your then blocks in to a promise chain, and often ignore intermediate values:

    let y, z;
    getY(x)
    .then(returnedY => { y = returnedY; return zPromise(); )
    .then(returnedZ => { z = returnedZ; return ......; }
    .then(......another side effect.....)
    .then(_ => f(y, z))

Practically:

    let y = await getY(x);
    let z = await getZ(y);
    ......another side effect....
    return f(y, z)

    getY(x)
      .then(returnedY => Promise.all([Promise.resolve(y), zPromise()])
      .then([y, z] => { ...another side effect...; return Promise.all([Promise.resolve(y), Promise.resolve(z), sideEffectPromise()])
      .then([y, z, _] => f(y, z));

2) catch's entire purpose is to be a catch-all for unexpected errors. For expected errors, it's better to have explicit error values. Bluebird.js at least lets you differentiate .catch from .error, where .error handles the explicit error values generated from traditional Node.js callbacks.

Do you have any good escapes l examples of further reading on this? I'm not sure I agree with this statement, or perhaps don't fully understand it. It seems like both cases boil down to functions as data (function pointers essentially) that are called at the end of some event or chain of events.

To me, they seem to be the exact same thing but worth promises being much more human readable.

  readThisFile: string -> (string -> void) -> void

  readThisFile('foo.txt', result => ...)

Hopefully that was clear enough to see that passing actions around is akin to controlling the flow with e.g. if-else, and that passing data around is declaring how your tubes/rail tracks/whatever analogy for monads are constructed, aka data flow.

>> functional event-driven code with contextual closures

This paradigm works very well on the server side too. Ex: A HTTP requests makes a query to a database server, then returns the result to the browser

This gives parallelism without the complexity of threads.

How about:

  async function main () {
    try {
      const responses = await Promise.all([
        fetch('https://api.github.com/orgs/facebook'),
        fetch('https://api.github.com/orgs/facebook')
      ]);
  
      const jsons = await Promise.all(responses.map(res => res.json()))
    } catch (err) {
      console.log(err)
    }
  }

    async function main () {
      try {
        const jsons = await Promise.all([
          fetch('https://api.github.com/orgs/facebook'),
          fetch('https://api.github.com/orgs/facebook')
        ]).map(promise => promise.then(res => res.json()));
      } catch (err) {
        console.log(err)
      }
    }

    async function main () {
      try {
        const jsons = await Promise.all([
          fetch('https://api.github.com/orgs/facebook'),
          fetch('https://api.github.com/orgs/facebook')
        ].map(promise => promise.then(res => res.json())));
      } catch (err) {
        console.log(err)
      }
    }

    async.parallel({
        facebook: done => request("https://api.github.com/orgs/facebook", done),
        twitter: done => request("https://api.github.com/orgs/twitter", done)
    }, (err, responses) => console.log(err, responses); );

    null, {
       facebook: { // facebook data },
       twitter: { // twitter data }
    }

In the same vein async.js will be catching all errors passed to done(err, response) and in the case of async.series() and similar calls, will stop the execution of concurrent actions as at the first error that is caught.

Therefore I think its completely valid, because even though our examples are different, to most developers it doesn't even matter.

I think you have a completely valid point, and it's probably a better world where we have proper error propagation and composition, just the reality of the situation is what it is.

Nobody who realized the fragility of async/callbacks and understanding what it takes with them to make at least a passably robust program would stay with async, they would quickly switch to promises/fibers/equivalent or stop using node. Although I have seen projects on github that use try-catch blocks properly with callbacks/async and I have to wonder what made them think that there isn't a better way.

And again, async does not catch any errors, it only forwards error callbacks based on some very loose convention which isn't even honored in core node apis. Just because most node (or rather callback/async) users are clueless about error handling doesn't make the examples equivalent.

IIRC Promise.all will run the two responses in parallel, but will not send the first into the map before both are finished.

Yeah, I know that. I don't mean .all schedules them to run (e.g. like doing thread.start()), of course they auto start.

By run I mean that inside the .all implementation syncs with you about their completion ("tells you when all of them are settled").

>It depends on your Promises whether they are doing something outside the single threaded event loop or not for them to be parallel or not.

That's not the point though, which was the parent's assertion about whether the first to resolve will escape .all and go into the .map, which I don't think is the case.

Which is why I'm a massive fan of Futures from ramda-fantasy[0] instead of Promises for certain tasks!

[0] https://github.com/ramda/ramda-fantasy/blob/master/docs/Futu...

There is, of course, no library needed to use pure promises for the same functionality, though.

My point is that all of this is possible without async/await, which to me are abstractions that cloud the landscape, obscuring the real evented nature of JavaScript that makes async programming so easy, IMO.

This is speaking from personal experience, albeit not in JS, but rather .NET. However, the story there is similar - .NET used callback-based continuations first (the Begin... pattern), then added promises (Tasks) in .NET 4.0, then finally async/await syntactic sugar in C# 5. We introduced tasks to our codebase pretty soon, but had to avoid await for a while because of the requirement for the code to be compilable with C# 4. When we finally dropped that requirement a couple of years later, and started moving to await, code became much simpler and cleaner as a result, and new code is also much easier to write, with fewer silly mistakes (like "I forgot to check for errors").

It absolutely does make sense. How many "class builders" have been written in the JS community since ES6 got classes ? That's right. Now you don't have to rely on co/thunk and what not to write readable async logic. Promises are still callbacks wrapped in objects. Now the consumer of a function that returns a promise doesn't have to deal directly with the promise anymore.

This feature is something JS should have had a long time ago, no question.

> This feels like a step toward added confusion rather than language unity.

Things like prototypical inheritance are the biggest source of confusion, along with "this" behavior.

> beneath native abstractions

The correct terminology here would be syntactic sugar.

Look you might not like this, but what is better ? community fragmentation with transpilers and what not, or a single language that answers most of the needs of the community ? libraries that handle complex abstractions or documented syntax that allows getting rid of these poorly documented and poorly maintained libraries? I don't want to use generators to mimic corroutines and depend on co/thunkify to write readable async code. I don't want to use 3rd party language X or Z that will get me the syntax I want, I want everybody to use the same language without obscure patterns.

The think I don't like about promises its that you need to write a lot of lines that you could avoid with async/await, i.e:

  new Promise(function(success, failure){
    db.fetch('sql...', function(err, data){
      if (err) failure(err)
      else success(data)
    })
  })

  var data = await db.fetch('sql...')

  promise.then(function(done, args){
      try {
        db.fetch('sql...', done)
      } catch(e) {}
    })
    .then(function(done, args){
      try {
        db.fetch('sql2... {args}', done)
      } catch(e) {}
    })
    .then....

  try {
    var data1 = await db.fetch('sql1...')
    var data2 = await db.fetch('sql2... {data1}')
  } catch(e) {}

I'm also in the boat of confused people of why is async-await requested by a good portion of the js community - wrapping the block within the function in a try-catch seems like a bad idea, a brute force mechanism. IMO this is language bloat, and does not really solve problems we have while introducing a more expensive vector for managing flow (try-catches).

One missed point about the .catch with promises is that it allows you to branch flow discretely - it is not a perfect solution for branching flow (it is awkward when branching due to more than just a binary outcome), but with await, one might end up writing repetitive code for certain flows where one expects common calls to be made downstream in async data fetching flows.

Depends whether you can survive and continue from an exception inside the .then to the next step or not.

e.g, naive example:

  .then(() => {
     var foo;
     try {
          foo = getFoo();
     } catch (err) {
          foo = 10; //some default value
     }
     return foo;
  }).then( (foo) => 

So you might not want to reject automatically inside then if getFoo raises, but recover and return a default value.

    .then(getFoo)
    .catch(err => 10) //some default value
    .then( (foo) =>

Being simple doesn't make them optimal.

Promises are a clutch for lack of a built-in language feature, and async/await is that.

They add extra visual clutter, they can eat exceptions [1], they break the intuitive flow of code, etc.

[1] Yes, only if they are used badly. That's kind of the point. C is an excellent language too if everybody never uses it badly. The thing is people do, and a feature/language that doesn't need a corner case or mental model to keep in mind is better than one that does in that regard.

In the end, as you pointed out, these construct may work against developers in large/concurrent codebases and is an undoing of the simplicity of Javascript, one of its original strength. On the other hand we can't really say this was not coming, Javascript being a single target language with many stakeholders around it.

Maybe what's needed is to stop teaching object-oriented/imperative programming as the main paradigm. But well before that happens, hopefully WebAssembly will create a evolutionary market for languages vs. a language by committee.

C++0x started adding the kitchen sink and that's when C++ jumped the shark. JS seems to be headed in the same direction...

async/await looks nice but doesn't scale. As soon as you have to do something other than wait for a callback it falls apart.

Waiting for a callback is what you do 90% of time. For the rest, you can always combine async/wait with Promises...