Hacker News Reader

Comment by josteink | Hacker News Reader

And for those sites, you can always use HTTP pipelining and avoid the whole SPDY can of worms.

Looking at the facts, it seems pretty obvious that whatever theoretical gains you can get in select scenarios with SPDY, this super-minor gain is not worth it compared to the associated complexity cost.

Not to mention I don't like the idea of Google now not only running the worlds tracking units, the worlds most popular browser and most popular websites, but now also dictating internet-protocols without taking input from other parties.

View on HN

They did not dictate anything, but proposed a protocol. It was adapted and changed.

Also, this is not part of a big, evil Google master plan. The engineers who developed it are well known and they presumably tried to do their best from a technical point of view.

What's the complexity cost in SPDY or HTTP/2's case?

For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.

>the tradeoff of getting the bundles right, which of course reduces cachability

If you are revving your bundles with hashes (main.8a4ce55.js), caching shouldn't be a problem. Not sure what your build process is, but there are plugins to do this on most setups.

That's precisely the point revving bundles with hashes is about destroying cachability.

When two separate resources together at build time they're being coupled from a caching point of view if one gets changed and the other doesn't they they both have to be re-downloaded because the bundle has changed.

> For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.

And all of this is a build-time problem.

If we're going to engineer the HTTP-protocol to solve build-tooling and development related problems, we might as well add JS-linting and minifying to HTTP itself as well.

Seriously: This problem is best solved elsewhere.

You've got it wrong the way around these aren't build-tooling and development related problems, they're problems with HTTP/1.x that we chose to solve using the build process.

Other parties sat around and didn't come up with and implement a good protocol, did they? Which browsers have pipelining enabled, 15 years after the spec? And at least SPDY has some binary format, not the optimized-for-composition-in-notepad text format.

Just testing SPDY on a site I was building last year, it seemed to provide double digit speedups. Not bad for my effort of typing SPDY into nginx.conf.

So yeah, I dislike Google. I use FF and disconnect search. I hate Google's intrusiveness and anti privacy stance. But at least SPDY provides actual benefits today, versus complaining about standards.

Excuse me if I think that sounds like a "We have to do something. This is something. So we must do this"-type argument.

More like "We have to do something to improve the situation. This is something that helps out. We have no other viable options at the moment. So we must do this."

Reply on news.ycombinator.com