SPDY is great and looking foward to support all around, but looking at that waterfall example, why the heck would anyone develop a website that loads that many elements all at once?
No-one has a viewport that large. You can do lazy image loading in just a few lines of javascript, without jquery. Scripts can be deferred, etc.
I fear SPDY is going to be yet another way to allow shoddy, lazy website functionality.
It may be not difficult to do lazy image loading in javascript but ideally you wouldn't have to do it at all. It doesn't encourage lazy or shoddy work. it just allows web developers to focus on creating value rather than just figuring out how to efficiently load images. It's kind of like the argument that garbage collectors are bad because encourage people to use memory inefficient designs, when in fact the reason that garbage collectors are good is because it allows you to focus on more important problems (like design and features). Sure every tool has a different way to shoot yourself in the foot but that doesn't mean you shouldn't use the tool.
tl;dr If SPDY lets me write a website without worrying about how many elements are loading at a time then ill have more time to spend on actually building a product.
You can do lazy image loading in just a few lines of javascript, without jquery. Scripts can be deferred, etc.
Those are hacks. I'd rather have a browser that loads stuff really fast and not have to jump through hoops like spriting, etc. If you're really concerned about deferring the loading of images, that could also be a feature of the browser.
Also, consider that asking the question, "why the heck would anyone develop a website that loads that many elements all at once," is like asking, "why the heck would anybody develop a program that doesn't fit on a 1.44MB floppy?".
HTML is a declarative format, so the presence of an <img> tag doesn't mean it has to be loaded eagerly. You could turn it around and ask why the browser is loading assets that can't be seen.
100,000,000 users, many with upwards of 1000 friends, with no obvious way to determine the most frequent?
You could sprite the top 100 users, but that wouldn't have much benefit to most people. Top 1000 is likely too big to send out to every user.
Just sending them as we do now is lots of HTTP requests. If we could somehow reduce the requests... Ah, pipelining, or even better the built in feature of SPDY.
In reality right now, Google+ uses SPDY for everything but the avatars, which are served over normal HTTPS from https://lh3.googleusercontent.com/. Wonder why?
You can do a lot of things, but why not just speed up the base functionality? Lazy-loading of images speeds up the experience over HTTP, and it will also speed up SPDY. There's only so much optimization you can do at the highest level. At some point, you need the lower levels to just go faster.
For instance header compression using a shared prefix dictionary saves only a handful (~100 bytes) over TLS compression -- worthless, not to mention it's already had several versions of the prefix dictionary.
Spdy developers didn't even test against HTTP tunneling, which in practice as seen in current Firefox and Opera works just as well. The 'head of line blocking' is not a big deal in practice.
No-one has a viewport that large. You can do lazy image loading in just a few lines of javascript, without jquery. Scripts can be deferred, etc.
I fear SPDY is going to be yet another way to allow shoddy, lazy website functionality.