1. This might not be built in a browser. e.g. Hulu or ESPN iOS app. Although any client of the byte stream could implement the "refreshing" protocol on the client, its more work for each client to do.

2. Given this is Cloudflare they are probably trying to find optimal ways to use bandwidth and their edge fleet. Like TV, maybe there will be no "rewind", and each Cloudflare edge server fans out the same "currently live" bytes to all available clients (i.e. shared state across all client connections, rather than independent state for each client connection). Which can't happen if there is a "refresh" event from each client that needs to be synchronized.

3. "refreshing" implies new state, added latency, and a "janky" feel. If "transitioning" is all server side, bytes from the next "episode" can be pipelined before the previous episode is finished and the refresh event has occurred.

    |-Episode A->|
    |-Episode A->|
    |-Episode A->|
    |          <-|
    |     <--Refr|
    |<--Refresh--|
    |->          |
    |de B->      |
    |-Episode B->|
    |-Episode B->|
    |-Episode B->|

Rather than:

    |-Episode   A->|
    |-Episode A/B->|
    |-Episode A/B->|
    |-Episode   B->|
    |-Episode   B->|
    |-Episode B/C->|

Breaks/introduces annoying amount of lag for people using things like mpv for an "actual" live television experience would be my guess.

This is just a guess, but JS only works in the context of a website, and it might actually be simpler to control the server side muxer without having a whole bunch of logic and the systems to support it.

I wonder if they have plans to expand to non-browser viewports?

They do. From the last section of the article, entitled "Thinking Ahead..."

> Bring Cloudflare TV to platforms like Apple TV and Roku