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
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.
1. Modern APIs
The most obvious difference between XHR and the Fetch APIs is the actual amount of code needed for similar tasks.
Take the following common example of making a request for a JSON resource with XHR:
Compare the same request using Fetch:
Slimming! Besides the fact that it takes less code to do the same thing, we are also able to take advantage of Promise-chaining rather than having countless callbacks that would result in a confusing mess. The Fetch APIs have been created with modern coding patterns in mind, along with sleek new interfaces, but we’re not done yet!
In addition to having a modernized API surface, developers get the fundamental primitives involved in a fetch operation: the Request and the Response objects. These low-level abstractions provide the flexibility to do more than what was previously possible with XHR. Specifically, we’re able to consume the underlying stream of a Response’s body instead of just retrieving the body as text.
Take the following example of streaming content from a large UTF-8 .txt file to a div on the page:
We are now able to buffer data as it comes in, and we don’t have to wait until it’s all there. Streaming the response body improves the site’s memory usage and gives a greater perception of speed when trying to show content over slow connections. In XHR, the whole response would be buffered, rather than being able to operate on the data in chunks. It’s possible to set up a stream in XHR, but it would cause the responseText to continuously grow, and you would have to constantly retrieve the data manually from there. In addition, the Fetch APIs provide access to the actual bytes of the data when streaming, whereas XHR’s responseText is text-only meaning that it can be very limiting in some scenarios.
For the time being, many users are still running browsers that may not support fetch, so it makes sense for web developers to continue to use XHR. However, that doesn’t mean that they can’t take advantage of Fetch today; GitHub’s Fetch polyfill, which is built on top of XHR, provides a great starting point for supporting browsers that do not have Fetch (with some limitations such as a lack of true streaming). Meanwhile, developers can take advantage of new capabilities introduced by Fetch (like true streaming) to progressively enhance experiences for user-agents that do support Fetch.
The road to Service Worker
When we talk about Fetch we are not just talking about the APIs that are meant to succeed XHR, we are also talking about the underlying algorithms and process of retrieving resources. In fact, XHR has been rewritten to be defined in terms of the Fetch algorithms, effectively making Fetch a superset of XHR. The Fetch spec also defines how every resource request is routed to and intercepted by a Service Worker.
Our journey for web apps on Windows began back in 2011, and in January we outlined our roadmap for the Fetch, Service Worker, and Push standards as the next evolution for better performance, offline experiences, and increased user engagement. Our implementation begins with the APIs defined in the Fetch spec, available in Windows Insider Preview build 14342. Our next step is to complete our implementation of the spec, including the ability to perform a fetch in a Service Worker context. And so today, we’re excited to begin development of Service Worker in Microsoft Edge.
Go on, give it a try!
You don’t have to wait until later this summer to get your hands dirty with the Fetch APIs in Edge – you can preview this functionality today via the Windows Insider Program (Fetch requires build 14342 or higher). You’ll be fetching better than your pet in no time at all! We’re truly excited to deliver this set of APIs, and we look forward to your feedback and experimentation.
– Ali Alabbas, Program Manager, Microsoft Edge
Updated May 25, 2016 8:34 am