That may be, but I've often needed to be familiar with the transport layer and all the quirks of how clients and servers handle connections, latency, etc. Only on those mythical "normal days" do I sit back and trust the abstractions completely, ignoring all of the underlying acrobatics.

I think he was speaking from the perspective of a web-server developer, who does have to deal with the complexities of the protocol implementation. Not everyone gets to be shielded from that stuff.

TLS is not HTTP. TLS is a layer below HTTP and largely a black box to a client or server implementer (as it should be, as it's very hard to get right).

SPDY is a replacement (or, in the inevitable future where http/2.0 effectively is spdy, an upgrade) for http. There is no way to write an http client or server without wildly divergent code paths.

* Note: When I say client or server I mean at a low level. I don't mean an app server running on a library that implements the http part.

How many people write Internet-facing HTTP servers, though? Usually even if you're writing a webapp framework, appserver host, or HTTP library, you'll stick Nginx in front of it.

There are a lot of security and DOS concerns that you have to worry about when exposing a server to the public Internet - it's usually best to let mature software handle that and proxy to your custom stuff, particularly when the mature software is already open-source.

How many people write anything? This kind of reductive reasoning would basically leave everyone in the world writing software that can fit nicely in a UML model generator.

It's entirely reasonable to ask if complexity is worth it on every level. Many of the greatest successes of internet protocols have come through making things as simple and modular as possible. This doesn't mean SPDY is terrible necessarily, but "no one ever needs to work with it" is a clearly wrong answer to a criticism that it's overly complex.

I guess my point is that as projects mature, there are usually fewer serious options on the market, and those options do more, and so it makes sense to capture a lot of the complexity inherent in the problem within those few pieces of software rather than force all users of that software (which are numerous) to deal with it.

Perhaps there are simpler solutions to the problem, but if they make things slower for end-users, that's inconveniencing millions to save effort for dozens, which is not a particularly good trade-off.