Intent to Ship: Response construction with ReadableStream
Yutaka Hirano
Contact emails
yhi...@chromium.org, tyos...@chromium.org, dom...@chromium.org, kenji...@chromium.org
Spec
https://fetch.spec.whatwg.org/
Tag Review request: https://github.com/w3ctag/spec-reviews/issues/121
Summary
A Response object represents a response of network-fetching. It’s also constructible by a developer, like
new Response("hello", {
status: 200,
headers: {"Content-Type": "text/plain"}
})
A response can be made from the body (the first argument) and other members (the second argument), and a developer can specify a body of various types, such as text, ArrayBuffer, Blob and so on.
This intent to ship is about allowing developers to specify a body with ReadableStream type.
We’re also shipping ReadableStream constructor in the same milestone in order to power this feature but we’ll focus on the gain of the response construction in this doc. See this appendix for the details of that.
Motivation
The ability to create a Response backed by a ReadableStream is extremely powerful in the context of ServiceWorker as it allows SW-controlled pages to stream data to greatly improve the Loading user experience. Concretely, the renderer of the page can parse and render the chunks as soon as they arrive, and therefore reduce the rendering latency.
This is particularly important in the context of progressive web apps that want to compose cached content with content fetched over the network. Assume a web app installs a ServiceWorker, and it traps a network request req in the onfetch handler. Part of the resource for req is available offline (e.g., a header and footer cached in the CacheStorage) but other parts need to be fetched from the network. By using this feature, a developer can create a partially-available Response, pass it to the main page, to eventually append remaining data chunks as they become available. The main-page can reduce the user-perceived latency through the progressive layout and rendering of the streamed contents. This is explained in more detail, with nice graphics and benchmarks showing the performance wins, in this post by jakearchibald@.
Side by side comparison. On the far right: with streams
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://jakearchibald.github.io/isserviceworkerready/demos/simple-stream/
(available on Chrome 51+ with chrome://flags/#enable-experimental-web-platform-features enabled)
You can also find some more demos in the article by Jake.
Debuggability
The response passed to the page can be monitored using the usual devtools support for inspecting network responses.
Interoperability and Compatibility Risk
The overall plan of Response streaming has been discussed on GitHub. As with many service worker features, this has been developed in concert with Mozilla for a long time over many GitHub threads. In the linked thread Mozilla’s point person for Service Worker and Streams, Ben Kelley, gave a positive response. There are no negative indications from other vendors with regard to response streaming. Additionally, much of the streams-related groundwork for response streaming (like the ReadableStream constructor) is already shipping in Safari Tech Preview (see this WebKit bug); WebKit developers have been very active in spec and test suite discussions.
As detailed in the appendix, this also involves a slight web-visible consolidation of the globals ReadableByteStream and ReadableStream to the single global ReadableStream, per recent spec changes. The compatibility risk here should be low, as the spec has explicitly warned developers that the name ReadableByteStream might change or go away, and it was only shipping in Blink.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/feature/4531143755956224
Rick Byers
Domenic Denicola
> "You've been warned" is unfortunately not sufficient justification to remove an API. The "webkit" prefixed APIs were all added with such a warning too and we know how well that worked out ;-). Did we actually ship a ReadableByteStream constructor? I don't see a constructor in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableByteStream.idl&q=ReadableByteStream&sq=package:chromium&type=cs&l=7. If it's possible that some app might be depending on 'new ReadableByteStream(...)' working, then we'll need to gather some compat data before removing (UseCounter, httpArchive, etc.).
>
> If we never actually shipped a ReadableByteStream constructor and you're just talking about the change in behavior of http://object.constructor.name, then yeah in practice it seems it's very rare to rely on that and the risk in this case is probably extremely low and (IMHO) doesn't require any measurement.
Right, sorry for being imprecise. The constructor was exposed (so e.g. window.ReadableByteStream existed), but it always threw.
Rick Byers
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
TAMURA, Kent
Software Engineer, Google