[striking]

Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people.

And thus, benchmarks are unhelpful.

I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, but there are so many issues and flaws left unfixed, with unhelpful bikeshedding occurring over perceived "performance".

[venaoy]

> And thus, benchmarks are unhelpful.

No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that.

> If this were called HTTP/1.2 ...

The mere fact you brought this up (no amount of backpedalling you may do after my comment on this) makes your criticism look even stupider. You should judge the spec based on its technical content, not based on whatever arbitrary version number was assigned to it. Talk about a bike-shed argument (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality)

[striking]

> benchmarks

The linked benchmark is flawed, as dlubarov noted above. I wanted to note that it is easy to write a flawed benchmark. And in this case, benchmarks are unhelpful, because my major lament is not efficiency or lack thereof, it is the lack of any new features or any consideration to any of the other pain points that exist on the Web today.

> doesn't mean all benchmarks are unhelpful

Didn't mean to imply that, although I can see how it could be read that way. Rest assured, I only believe benchmarks are unhelpful here. Oftentimes a benchmark is the best way to quantify usability, such as DoYouEvenBench (http://www.petehunt.net/react/tastejs/benchmark.html)

> backpedalling

I won't backpedal. This is important, actually, because the name it's given lends it some intrinsic hype. Let's say you're Google, and you're pushing a web standard that benefits you more than anyone else. What's more likely to be adopted, "HTTP/1.2" or "HTTP/2" ? It is important, in my opinion.

[venaoy]

> The linked benchmark is flawed, as dlubarov noted above.

No, I already replied to him. You and him should spend some time looking at the Chrome network console visiting some of the top500 sites. It is very common for sites to be exactly like that: tons of small requests for small resources.

[striking]

Okay. Fair enough. I concede that efficiency is important and that SPDY / HTTP/2 can improve upon it. But I don't believe that this is worth the hype because the exposed featureset is otherwise tiny. Efficiency is cool, yes, but I'm personally waiting until HTTP/3 fixes the other wrong things with the Internet before I implement anything. I think the amount of effort that goes into this is not worth the result. Why include tons of small resources on your page if they're not necessary? Why revamp a protocol entirely if all you have to do is stop including tons of small resources?

[venaoy]

> Okay. Fair enough. I concede that efficiency is important and that SPDY / HTTP/2 can improve upon it.

Great, I appreciate you recognize this.

> Why include tons of small resources on your page if they're not necessary?

But it _is_ necessary. In every single of the examples I gave in my reply to dlubarov, it is necessary:

- There are 100+ small images, icons, etc and all are displayed on the nytimes.com homepage.

- All of the thumbnail pictures of ebay items on a listing are displayed to the user.

- The 50+ maps tiles downloaded when browsing Google Maps are all necessary.

- Etc

You seem to fail to realize that in 2015, not every web page can be dumbed down to a blob of static HTML and no more than 2-3 images. The modern web is complex. We needed a protocol that can serve it efficiently.

[enneff]

It's not just web _pages_, either. Many people spend their days working in web applications, which HTTP/2 helps tremendously.

[izietto]

> there are so many issues and flaws left unfixed

Can you explain this point?

[taf2]

so your only real issue is with the version number.