Like all good puzzles, a web browser is composed of many different pieces. Some are all shiny, like your favorite web API. Some are less visible, like HTML parsing and web resource loading.

Even dull pieces require lots of work to standardize their behavior across browsers. For example, HTML parsing originally provided only: Give me HTML and I’ll give you a document. Now, it is much more reliable across browsers because it has been standardized in detail. Similarly, the loading of web resources was somehow consistent up to: give me an HTTP request and I’ll get you a HTTP response. But loading a web resource encompasses much more than that. The Fetch specification thoroughly standardizes those details. As well as specifying how the browser loads resources, the Fetch specification also defines a JavaScript API for loading resources. This API, the Fetch API, is a replacement to XMLHttpRequest, providing the lowest-level set of options possible in the context of a web page. Let’s see how shiny Fetch API might be.

The Fetch API

The Fetch API consists of a single Promise-returning method called fetch . The returned value is a Response object which contains the response headers and body information. Let’s use the Fetch API to retrieve the list of WebKit features:

async function isFetchAPIFeelingGood () { let webkitFeaturesURL = "https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/features.json" ; let response = await fetch ( webkitFeaturesURL ); let features = await response . json (); return features . specification . find (( feature ) = > feature . name = = "Fetch API" ); } isFetchAPIFeelingGood (). then (( value ) = > alert ( ! ! value ? "Oh yes!" : "not really!" ))

You might notice two await uses in the example above. fetch is returning a promise that gets resolved when the response headers are received. The data being requested is JSON. The second promise resolves when the entire response body is available.

fetch can take either a URL or a Request object. The Request object allows access to a whole new set of options compared to XMLHttpRequest. Let’s try again to check whether fetch API is supported in WebKit, but this time, let’s make sure our cache does not serve us some out-of-date information.

async function isFetchAPIFeelingGoodForReal () { let webkitFeaturesURL = "https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/features.json" ; let response = await fetch ( new Request ( webkitFeaturesURL , { cache : "no-cache" } )); let latestFeatures = await response . json (); return latestFeatures . specification . find (( feature ) = > feature . name = = "Fetch API" ); }

fetch also provides more flexible access to the response body. In addition to getting it in various flavors (JSON, arrayBuffer, blob, text…), the response provides a ReadableStream body attribute. This makes it possible to process chunks of bytes progressively as they arrive without buffering the whole data, and even aborting the resource load:

async function featureListAsAReader () { let webkitFeaturesURL = "https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/features.json" ; let response = await fetch ( new Request ( webkitFeaturesURL )); return response . body . getReader (); } function checkChunk ( searched , buffer , count ) { var i = 0 ; while ( i < buffer . length ) { if ( buffer [ i + + ] = = searched . charCodeAt ( count )) { if ( + + count = = searched . length ) return count ; } else if ( count ) { - - i ; count = 0 ; } } return count ; } async function isFetchAPIFeelingGoodWhileChunky ( reader , count ) { reader = reader ? reader : await featureListAsAReader (); count = count ? count : 0 ; let chunk = await reader . read (); if ( chunk . done ) return false ; let searched = "Fetch API" ; count = checkChunk ( searched , chunk . value , count ); if ( count = = searched . length ) return true ; return isFetchAPISupported ( reader , count ); }

Fetching The Future

The Fetch API journey is not finished. New proposals might cover important features of XMLHttpRequest that Fetch currently lacks, like early cancellation and timeout. New proposals might also cover HTTP/2 push and priority, as well as wider use of the Response object in web APIs: media elements, Web Assembly… The Fetch algorithm is also being constantly refined to reach full interoperability of web resource loading. A first iteration of WebKit Fetch API implementation shipped in Safari. The WebKit community is eager to hear about your feedback on this feature. Comments, suggestions, priorities, use cases, tests, bug reports and candies are all very welcome through the usual WebKit channels. That would be so fetch indeed!