This thread has a much more in-depth discussion on the considerations for designing this API: https://github.com/whatwg/fetch/issues/27 https://github.com/whatw

This thread has a much more in-depth discussion on the considerations for designing this API: https://github.com/whatwg/fetch/issues/27 https://github.com/whatwg/fetch/issues/27 One key point is: since a promise can have multiple then-subscribers interested in it, (a) is it the subscriber's responsibility to signal disinterest (in which case the promise-creator needs to reference-count interest/disinterest)? Or (b) is it the promise-creator's responsibility to unilaterally cancel things, and the entire dependency tree must figure out how to fail elegantly? Either way, in a cancellation world, subscribers need to be rewritten either to (a) indicate disinterest, or (b) handle a cancellation coming from upstream, which is semantically distinct from an error. Bluebird (whose designers seem to be involved in that thread) handles (a) pretty elegantly - it's subtle, but cancelablePromise.then() increments the reference count and returns a cancelablePromise that, when it or its descendants indicates disinterest, decrements the reference count: http://bluebirdjs.com/docs/api/cancellation.html http://bluebirdjs.com/docs/api/cancellation.html But I'm not quite convinced that this needs to be handled at the Promise spec level. If you're going to be adding "finally" clauses anyways, why not just use (b), special-case a type of "catch" and just not toast/console.error the exception if it was a CancellationError? All this complexity, though, indicates the need for declarative data dependencies a la Relay or Meteor. Making the application programmer handle fetch/cancellation logic will be seen as an anti-pattern once those patterns reach maturity.