Re: [fetch] Aborting a fetch (#27)

I'm not confused about Promises. I think they are easy to understand today. A relatively large community understands them and their de facto standard status is one of the reasons why they were integrated into JavaScript. 

The current promise cancellation proposal is not a de facto standard. A small number of people thought it up a few weeks ago. We have no evidence that it will be easy for developers in the community to understand. I think it's fair to say that it adds a good deal of complexity to Promises, and there's no guarantee that the wider community will easily understand it.

Today there are more people who use Observable than cancelable promises. That number is likely to increase sharply in the near future, because Angular 2 and React both currently plan to use Observable to model data fetches. Both these teams took a look at Promises and decided that they were inadequate for a fetch API. Why not change fetch to return an Observable and let Promises continue to be a well known quantity? Observable is moving through the JavaScript standardization process. There is already an interoperability spec being used by multiple frameworks.

https://github.com/jhusain/observable-spec

JH

> On Apr 17, 2015, at 12:23 AM, Andrea Giammarchi <notifications@github.com> wrote:
> 
> @getify please stop saying "people" are confused about Promises ... nobody is!
> 
> Fetch API is specd as Promise, either we change this or we bring .cancel in: pick your poison
> 
> I'm all in favor of .cancel as finally 'cause it has a synchronous counterpart and makes Tasks let's say less needed. I also think that if I am asking you to promise me something, I should be able to tell you I regret I've asked that and you don't have to fulfill it ... but again, philosophy and synchronous counter part aside, we have a problem here, and we should solve it ASAP.
> 
> —
> Reply to this email directly or view it on GitHub.
> 


---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-96714261