Deprecate fetch about fetch

[annevk]

To be clear, the problem with XMLHttpRequest is that it does not support "no-cors", does not deal with Request and Response objects, etc. All of those are essential in a service worker world.

[NekR]

So point is what fetch is needed only for ServiceWorkers?

To be clear too, we (maybe only me) do not think what XHR is best API ever. We just saying fetch cannot replace XHR, but it's promoted as it can. Also, XHR can easily have most of fetch parts, such as Streams, no-cors mode and so on.

So, by no doubts, it's very good to have separate from XHR low-level API with Stream and other cool things which will allow 100% implement XHR over it. In the mean time, fetch with all its Promise-like-style-way is more suitable for simple interactions, just fetch and use data, like JSON. Fast. Simple. Strong.
Streams and other low-level stuff seems cumbersome over fetch.

[jakearchibald]

Can you show (with code) how streams are cumbersome with fetch, in comarrison to an XHR-based API?

With fetch:

fetch(url).then(response => {
  var reader = response.body.getReader();
  var decoder = new TextDecoder();
  function drain(valueSoFar) {
    return reader.read().then(function(result) {
      valueSoFar += decoder.decode(result.value || new Uint8Array, { stream: !result.done });
      if (result.done) return valueSoFar;
      return drain(valueSoFar);
    });
  }
  return drain();
}).then(function(fullText) {
  console.log(fullText);
});

With async/await:

fetch(url).then(async response => {
  var reader = response.body.getReader();
  var decoder = new TextDecoder();
  var fullText = '';
  var result;

  do {
    result = await reader.read();
    fullText += decoder.decode(result.value || new Uint8Array, { stream: !result.done });
  } while (!result.done);

  console.log(fullText);
});

[annevk]

Closing this as none of this is very actionable.

[NekR]

Why closing it? I have not enough time to argue with you all the time because full-time job, family, other things. There was enough arguments in "Aborting fetch" thread and still are. There was enough arguments in the Internet itself too. All this seems like you are blind. If you not planning to consider this issue at all and will ship fetch anyway regardless any feedback, then just say it -- "we do not case, we will ship it anyway". This will be perfect Open Web.

[NekR]

Particularly you may see this comment: #27 (comment)

[annevk]

fetch() has already shipped, as far as I know. (And has been specified in this way for over ten months, and agreed upon much longer than that.) In any event, there's many platform APIs that return promises where we might want to cancel the underlying activity. This is not novel.

[NekR]

It's shipped only to ServiceWorkers and behind the flag in the stable releases, according to this page: http://caniuse.com/#search=fetch

Here is for example my first filled issue about aborting problem with fetch https://www.w3.org/Bugs/Public/show_bug.cgi?id=27841 it's dated by 2015-01-16, almost 3 months from now. I believe there was not much promotion about it in those 10 months and not enough now. So I do not see here or in #27 web-devs arguing what fetch is very good.

In any event, there's many platform APIs that return promises where we might want to cancel the underlying activity. This is not novel.

This only means what not only fetch has problems and what not all should be built around Promises, at least while there is not good solution for canceling them. And best solution of course is to not use Promises.

As you may notice, we all who are against fetch with Promises trying to solve cancellation problem. There are few good proposals by @WebReflection and even one by myself. We can live with fetch and cancelable Promises, as far as they will be cancelable. But this all seems what you are planning to ignore all things proposed by different people and again decide all off-line.

One more thing -- Promises nature is not about cancelation in general and by shipping more-and-more API with Promises which should be cancellable you are doing same mistake again-and-again. It's not too late for ES7 to not use Promises as a basis for async/await since Promies does not fill all the requirements.

[annevk]

But this all seems what you are planning to ignore all things proposed by different people and again decide all off-line.

As far as I can tell @jakearchibald is doing a great job at making progress. You don't make progress with lots of repeated arguments though, you need to experiment, talk to the wider community, etc. Which is why he's probably not always updating that thread, which has over a 100 posts now and does not seem any closer to a solution.

[NekR]

which has over a 100 posts now and does not seem any closer to a solution.

This is exactly a point why same arguments are pops up again and again :-)

[jimmywarting]

who would have thought that fetch has now taken over the good old xhr in modern code standards, deno and node now ship with fetch built in.

still wish to see fetch deprecated? :P