Starting in EdgeHTML 14, coming with this summerís Windows 10 Anniversary Update, Microsoft Edge will support the highly anticipated Fetch APIs. This represents the first step in our planned journey to supporting Service Worker in a future release. You can preview the Fetch APIs in Windows Insider Preview builds starting with EdgeHTML 14.14342.

XHR: the beginning

The journey to Fetch started with XMLHttpRequest (XHR), first pioneered in IE5 (as part of the MSXML ActiveX control) and now one of the foundational components of modern web functionality. Most sites today use XHR, often via a helper method that abstracts away its unpleasantness (such as the $.ajax() method in jQuery), rather than directly (for example, via the open method, setRequestHeader method, send method, and onreadystatechange event listener). One of the many reasons to use a JavaScript library such as jQuery is to make it easier to interface with XHR, especially when these libraries take advantage of new JavaScript concepts such as Promises.

Along came Fetch

Unfortunately, libraries arenít well-equipped to interact with the low-level constructs of requests and responses, because the XHR APIs do not expose those concepts. More importantly, there hasnít previously been a way to get at any resource request that occurs in the browser, for instance, the CSS files and image files included as part of the HTML of a page. Developers were only able to operate on requests and responses when making explicit XHR calls in JavaScript. This posed an interesting challenge for newer features, such as Service Worker, which needed to intercept any fetch that occurs in the browser, as well as features that relied on a standardized process by which resources can be retrieved, such as sendBeacon.

Because of this, the web needed a new spec to unify the concepts of fetching resources, CORS, and redirect handling across the web platform. There was also a need to introduce new APIs that would give access to the primitives that would allow interfacing with the requests and responses.

Why not extend XHR?

The XHR2 spec prioritizes backwards compatibility with the first iteration of XHR; this resulted in XHR2 being restricted to XHRís dated object model. Building a brand new API from the ground up means it can be unshackled from the old APIís model. XHR could have been extended to have the same capabilities of the Fetch API, but it would have been an ad-hoc addition that would have made little sense in the context of any and all resource requests from the browser. Starting over and introducing the lower-level primitives that represent the requests and responses allowed for a far more extensible and robust API that also leverages new platform primitives such as Promises.

To fetch or not to fetch?

All of this raises the question of why developers should use the new Fetch APIs if they can already accomplish the same tasks with XHR. Letís walk through a few of the several reasons for using the Fetch APIs: modern APIs, streaming, and future-proofing...

Read more: Fetch (or the undeniable limitations of XHR) | Microsoft Edge Dev Blog