Re: [whatwg/fetch] History behind the decision to make fetch return a Promise (#611)

Just saw this thread per [twitter conversation](https://twitter.com/annevk/status/1060879259747672066). Hopefully recollections are still helpful. Here are mine:

When we sat down to work through the "navigation controller" design -- largely at the Mozilla London offices on St. Martin's Lane -- we quickly settled on a worker type, but knew from experience that it couldn't have synchronous APIs. That meant we were either going to have to design a new subtype of XHR (which was universally loathed) that was both promisified and sync-XHR-free, or we would have to design a new thing. 

The argument for "new thing" was that everyone sort of wanted it anyway, that retrofitting XHR for promises and `Request`/`Response` types was bound to be a huge effort, that defining an async-only version of XHR for one context (but not all) was going to be "weird", and that we wouldn't get the chance/excuse again. On the other side was "well, XHR works, sooo....".

Those arguments were effectively the same ones that were repeated over and over again until `fetch()` shipped.

We played around with many different forms and shapes of the API, IIRC, and pretty quickly got comfortable with the new method given how frequently it showed up in code we were working through.

Perhaps interestingly, the intensity of the various fights over Promises seemed to make `fetch()` less controversial. Once you had `Promise`, `fetch()` seemed inevitable and the wrapping/unwrapping and cancellation debates quickly eclipsed discussion of whether or not `fetch()` was a good idea.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/611#issuecomment-437429333