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
Along came Fetch
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...