SPDY and WebSocket both have protocol negotiation and framing but they are implemented differently. That's why Microsoft's S+M proposal essentially recasts SPDY on top of WebSocket so they can share the negotiation and framing code.

Despite being entirely different beasts from a design perspective, they solve essentially the same problem: bidirectional communication designed to minimize latency over a single established TCP connection, with protocol-internal notions of channels and framing.

That's only superficially accurate, working in the same way as the first graf of Spolsky's "Architecture Astronauts" post from several years back:

http://www.joelonsoftware.com/articles/fog0000000018.html

In reality, SPDY and WebSockets have two very different goals:

* SPDY is a transport optimized for the HTTP request/response service model, down to specific features to compress HTTP-style headers.

* WebSockets is a transport optimized for tunneling bidirectional application-level protocols over an HTTP-style transport.

I love the anecdote (and loathe working with that stereotype), but don't think it applies here. We're not exactly drawing a box labelled "DATA", one labelled "SERVER", and drawing a line between them: these protocols are significant, incompatible implementations that do almost the same thing internally, and interact equally as badly with the remainder of the stack externally. To say the similarity is only superficial seems inaccurate.

It's a bit like redesigning a car from scratch just because you need snow chains for certain roads, and upholstery covers for certain passengers.

This "architecture astronaut" phrase. I don't think it means what you think it means.

The two descriptions you make below describe much more essentially than superficially or "astronautically", the same kind of thing, optimized for slightly different use cases (not even THAT different).

I didn't call anyone an architecture astronaut; I'm just citing the first paragraph of that post.

> Would that have yielded something better?

It would have yielded the same thing as W3C's decade long stagnation during the development of XHTML: everyone gets bored and they set up WhatWG instead.