> Promises are not the only way to do async work in JS, as much as some people like to say that. You have observables and channels, which are more powerful beca

> Promises are not the only way to do async work in JS, as much as some people like to say that. You have observables and channels, which are more powerful because they handle streaming. Let me just try and translate that into sync-land: "Single value variables are not the only way to do work in JS, as much as some people like to say that. You have arrays and queues, which are more powerful because they handle multiple values" (my point being, different abstractions are useful for different things and/or in different ways) > There are proposals to make async/await more composable: https://github.com/jhusain/compositional-functions https://github.com/jhusain/compositional-functions. TC39 is aware of this but I'm not sure if they are going to fix it or not. I agree, but I don't think we need async/await at all. http://spion.github.io/posts/es7-async-await-step-in-the-wrong-direction.html http://spion.github.io/posts/es7-async-await-step-in-the-wro... > You shouldn't be forced to run code inside a try/catch. How is throwing on typos useful? The real solution for that isn't letting errors get through. Its having a type system like TypeScript or Flow plus using a sensible library like bluebird that reports rather than swallows up unhandled errors by default. Afaik errors from native promises are reported to the console in most browsers. And there are also tools like this: https://github.com/emberjs/ember-inspector/wiki/Promises-Tab https://github.com/emberjs/ember-inspector/wiki/Promises-Tab Allowing thrown errors to propagate synchronously will destroy many contractual guarantees that make promises useful in nodejs. For example, we would have to remove this entire section in Bluebird: https://github.com/petkaantonov/bluebird/blob/master/API.md#promiseusingarraypromisedisposer-promises-function-handler---promise https://github.com/petkaantonov/bluebird/blob/master/API.md#... and instead fall back to process crashing and restarting. Lack of error catching is what makes node unable to provide a safe solution to the crashing problem (and domains capture errors in both directions of the call stack which leads to problems inside node internals). Promises neatly solve that by providing a sensible error capturing and propagation model that isolates node internals from promise code: https://github.com/petkaantonov/bluebird/issues/51 https://github.com/petkaantonov/bluebird/issues/51