Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Fetch API vs XMLHttpRequest

People also ask

What's one major difference between XMLHttpRequest and the fetch API?

The main difference between Fetch and XMLHttpRequest is that the Fetch API uses Promises, hence avoiding callback hell. If you are new to promises then check out JavaScript Promises: an Introduction . You can make use of polyfill for browsers that are not currently supported.

Is fetch API better than Ajax?

Fetch is compatible with all recent browsers including Edge, but not with Internet Explorer. Therefore, if you are looking for maximum compatibility, you will continue to use Ajax to update a web page. If you also want to interact with the server, the WebSocket object is also more appropriate than fetch.

What can be used instead of XMLHttpRequest?

The Fetch API is a modern alternative to XMLHttpRequest . The generic Headers, Request, and Response interfaces provide consistency while Promises permit easier chaining and async/await without callbacks.

Is fetch API better than Axios?

Without question, some developers prefer Axios over built-in APIs for its ease of use. But many overestimate the need for such a library. The fetch() API is perfectly capable of reproducing the key features of Axios, and it has the added advantage of being readily available in all modern browsers.


There are a few things that you can do with fetch and not with XHR:

  • You can use the Cache API with the request and response objects;
  • You can perform no-cors requests, getting a response from a server that doesn't implement CORS. You can't access the response body directly from JavaScript, but you can use it with other APIs (e.g. the Cache API);
  • Streaming responses (with XHR the entire response is buffered in memory, with fetch you will be able to access the low-level stream). This isn't available yet in all browsers, but will be soon.

There are a couple of things that you can do with XHR that you can't do yet with fetch, but they're going to be available sooner or later (read the "Future improvements" paragraph here: https://hacks.mozilla.org/2015/03/this-api-is-so-fetching/):

  • Abort a request (this now works in Firefox and Edge, as @sideshowbarker explains in his comment);
  • Report progress.

This article https://jakearchibald.com/2015/thats-so-fetch/ contains a more detailed description.


fetch

  • missing a builtin method to consume documents
  • no way to set a timeout yet
  • can't override the content-type response header
  • if the content-length response header is present but not exposed, the body's total length is unknown during the streaming
  • will call the signal's abort handler even if the request has been completed
  • no upload progress (support for ReadableStream instances as request bodies is yet to come)

XHR

  • there's no way to not send cookies (apart from using the non-standard mozAnon flag or the AnonXMLHttpRequest constructor)
  • can't return FormData instances
  • doesn't have an equivalent to fetch's no-cors mode
  • always follow redirects

The answers above are good and provide good insights, but I share the same opinion as shared in this google developers blog entry in that the main difference (from a practical perspective) is the convenience of the built-in promise returned from fetch

Instead of having to write code like this

function reqListener() {
    var data = JSON.parse(this.responseText);
}

function reqError(err) { ... }

var oReq = new XMLHttpRequest();
oReq.onload = reqListener;
oReq.onerror = reqError;
oReq.open('get', './api/some.json', true);
oReq.send();

we can clean things up and write something a little more concise and readable with promises and modern syntax

fetch('./api/some.json')
    .then((response) => {
        response.json().then((data) => { 
            ... 
        });
    })
    .catch((err) => { ... });