Should this wrapper use native fetch, when available?

[kategengler]

I spent some time today writing some tests to expose what I thought was a bug here -- the polyfill is always used by ember-fetch; it will never fall back to native fetch, even when its available.

I was sure this was a bug until I found pretenderjs/pretender#60 with comments indicating that it was intended that this addon always uses the polyfill.

It's been almost a year since those comments, and Chrome and Firefox now appear to support fetch (http://caniuse.com/#search=fetch), should the native fetch be used, if available? Alternatively, a note in the Readme about why it always uses the polyfill would be great.

Incidentally, I started down this path when someone told me they were using ember-network + fetch and were also using ember-cli-mirage for testing on a recent Chrome and I felt I had to solve the mystery of how that worked. So, I have no real use case here and I certainly don't mind it using ajax. It does make testing easier that way, at least until pretender supports fetch.

[stefanpenner]

I don't believe we should use native fetch, the reason is as follows:

• the polyfil (as-is) doesn't cover the entire API surface
• having features that only work in non-polyfilled version, leads our users down a trap (IMHO).

The idea of this library was to explore the fetch API, and make it so users using it could in the future migrate cleanly to the real thing.

I would love to make it fallback when possible, but only feel comfortable doing so if it doesn't end up being a trap.

[stefanpenner]

will reopen if someone disagrees with my above statement, and we can revisit.