Editorial changes to transferable streams explainer

[ricea]

• Make some language clearer.
• Add a section about end-user benefit.

[torgo]

Hi! I think this is an improvement. Ideally I'd like to see an example - like a snippet of an end-user story where this creates better perceived performance. Also note the word "jank" is also a bit buzzwordy. Something like "a webapp that incorporates a stream of data that doex XYZ would have better perceived performance because the processing of handling & decoding the stream could be offloaded onto another thread." ?

[torgo]

I opened up a TAG issue on this just to cross-refernece. I know you haven't requested formal TAG feedback on this yet - it's just so we can keep track of it and put it on the agenda for the next call.

w3ctag/design-reviews#332

[ricea]

@torgo Sorry for the delay. How does the latest version look?

[travisleithead]

I was a little concerned that Transferable Streams would make it pretty easy to route data around the cross-origin restriction, but I don't think this feature makes it much worse than it already is--namely, today an origin A can postMessage the received chunks from a ReadableStream to origin B's message handler. With this feature, only one postMessage is needed to pass the Stream, and then origin B can drink from the pipe for as long as it likes.

I do think the explainer needs to support a better use-case than the general "workers make things easier", or "delegation is good". After all, the workaround for not having this feature is really trival--just make the request for Stream in the Worker/Frame instead (so the transfer is unnecessary). What are the use-cases where the Worker/Frame would be unable to implement that workaround? Why? (The only cases I can imagine are to enable easier cross-origin information sharing on the client.)

[MattiasBuelens]

After all, the workaround for not having this feature is really trival--just make the request for Stream in the Worker/Frame instead (so the transfer is unnecessary). What are the use-cases where the Worker/Frame would be unable to implement that workaround? Why?

Sure, since fetch is also available inside a worker, you could just as well have the worker request the data. However, for some use cases, you have to touch the main thread to access certain functionality:

• The stream may be coming from an input device only accessible on the main thread. You could use MediaRecorder to capture the audio of a user's microphone and/or the video of a user's camera, pipe the captured data through a off-thread TransformStream to transcode it into a hypothetical new experimental media format and then upload the resulting stream to a server.
• The stream may need to be displayed on the web page. You could invert the previous example: you download a stream of a video file encoded in an experimental media format, you transcode it to a natively supported format in a worker, and finally you transfer the resulting stream to the main thread to play back the video using <video> and MediaSource.
• You could have a video editing application as a pure web application, which basically combines the ideas from the two previous examples. You load a local video file or record video from your camera, transcode it in a worker and then store the result to a local file.

(Disclaimer: if I sound slightly biased towards video-related use cases, that's probably because I work for a company in the online video industry. 😛 )

[ricea]

I was a little concerned that Transferable Streams would make it pretty easy to route data around the cross-origin restriction

It's equivalent in power to a MessageChannel, so it doesn't weaken any security guarantees.

I do think the explainer needs to support a better use-case than the general "workers make things easier", or "delegation is good".

It is currently only an ergonomics win, although I hope to add optimisations in future exploiting the fact that the platform understands the semantics of the transfer. I think it opens up the benefits of offloading work to a larger audience, and that's where the end-user benefit comes from.

I will try to incorporate @MattiasBuelens's examples into the explainer.

[MattiasBuelens]

Spotted a few typos. Looks good though! 👍