Performance and Opportunities of HTTP 2.0
heavybit.com
heavybit.com
Meanwhile Microsoft published data showing pipelining to be basically the same speed as SPDY, and one of Google's pages (maps IIRC) loaded much slower with SPDY then plain HTTP because of a priority inversion, so priority codes had to be embedded in the site content.
So there's this much more complicated single connection, with priorities and "TCP-over-TCP" and dubious performance benefits. Why? I wonder how long Google will allow each request to come from a different connection. That seems to be where they are headed with this.
To add to your examples, Google claims resource sharding is bad and complex and "hacky", and criticize this for possibly breaking client-side caching and invalidating HTTP proxy support.
Then they move on to show how "wonderful" server-push is with the example of a request for index.html also pushing index.js and index.css, two files almost guaranteed to be cached more than 99% of the time. As if that doesn't break caching.
So you have a possibly hacky thing you may do which may break something, which is bad. And then you have a new protocol feature causing the exact same problem. And that is good. Hey Google: Make up your mind, already!
Yeah. Not sold at all. HTTP 2.0 is a terrible protocol, and not because it doesn't do enough, but because it does too much. It attempts to solve problems not belonging to the application layer.
HTTP 1.x was a nice, simple, stateless text-mode protocol. This thing is a terrible, state-full, impossible-to-debug Rube Goldberg machine and has nothing in common with that simple and nice protocol whose name it attempts to piggyback on.
That's the problem.
With a big enough screen, a sticky video with transcript below does make sense. Perhaps only make it sticky when the video starts playing though?
As it is, it just appears as a huge waste of space blocking my browser window...
Some way to collapse the video 'banner' into a smaller area, so we can use the full screen, or nearly, when reading the transcript, would be welcome. Perhaps if you click on the transcript to open the video at that point, it could expand again.
But yeah, agree with you. Particularly in this format, where there's so much value in the transcript below it, it'd be better to not have anything sticky. Like YouTube/Vimeo, where sometimes I go down to continue reading, and leave the video playing on top (off screen).
Regarding the format of the webpage: The video completely blocks my laptop browser window in Firefox v. 31.0, making it almost impossible to read the transcript. Sticky HTML elements on text-content heavy pages drive me crazy. Awhile ago I made a simple bookmarklet that makes me a much happier consumer of such pages. One version of it walks the DOM and unaffixes fixed DOM elements. The other changes them to display: none. You can roll your own pretty easily, or try out the ones I made at StaticDing.org. They both make it easy for me to read the transcript of Ilya's presentation. Without them, I probably would have given up.
Edit: I like what you are doing on mobile since you are hamstrung without many options, maybe on iPad portrait and wider you could go for a 2 column approach with the video on the left in a "sidebar" and the text flowing on the right? Again, just an idea. At any rate what you have is fine and gets the point across and I'm just being picky!