Hacker News Reader

Comment by blueskin_ | Hacker News Reader

I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.

View on HN

I really don't see the point of stuff like SPDY and WEBP/WEBM.

The former is generally more performant that HTTP, and the latter also offer benefits versus other options.

They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.

This is dangerously wrong, for two reasons:

1. These are open standards. They're not proprietary. 2. What is "improving things" if not proposing open, alternative standards which solve existing problems?

you know what else offered more benifits?

WMA over MP3, WMV over AVI.

And both are proprietary.. moreover you're mixing formats and containers

The difference is that Google has actually submitted SPDY as a possible basis for HTTP/2.0.

Too bad that it looks like it's going to be accepted, but that's a different issue alltogether (yeah. I don't like where HTTP/2.0 is going, but I can only "blame" the IETF, not Google).

Microsoft back then had no intention of submitting their changes to any standards body and was actually using patents and copyrights to ensure that it was difficult to impossible to reimplement their changes.

What don't you like about where HTTP/2.0 is going?

Can't speak for the person you're responding to, but personally, I don't think it makes sense for a semantically-similar but different in wire characteristics protocol to be called http/2.0. Nor do I think spdy has been around anywhere near long enough, nor been adopted organically enough, to justify being rammed through a process that seems to have been started almost specifically to get it that moniker (the call for proposals for the starting point was for less than a year, with only one possibility deployed at all, it was a foregone conclusion).

The whole process had the feel of a sham. SPDY should have evolved as its own protocol, continuing under the spdy name, and http/2.0 should have simply evolved to a semantically-driven protocol with standard negotiation mechanisms for choosing the wire protocol (which could be the MIMEish thing we have now or SPDY). This would have been a good way to ensure the web has a solid upgrade path.

It doesn't define high level semantics other such as QUIC can use or build from.

It's the whole kit and caboodle when it should have been broken up into clean modular pieces: framing layers, protocol layers, semantic layers. QUIC or other hopefuls trying to break from the mobile-horror-show that is TCP are left with nothing to start from, and HTTP/2 docs devolve into a commingled big-ball-of-mud as it hops from low level aspects to higher level aspects.

HTTP/2 doesn't prevent us from using lower-level protocols like QUIC, though. HTTP/2 over QUIC would work just as HTTP/2 over TCP

Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?

Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.

It's a new protocol, what do you expect? Tooling will improve over time.

> It's a new protocol, what do you expect?

It's in use in significant capacities on the most-tracked websites with impressive results you are welcome to easily see for yourself firsthand on your own server. More browsers than Chrome support it. More than one popular server supports it, with Nginx bundling it. CDNs are getting on board. Etc. This is the first somewhat-negative article I've run into about it.

That Google keeps working on it and releasing new drafts rather than kicking back and leaving it alone for the sake of creating an appearance of maturity, tabling better ideas they come up with for later, I don't think is a sign of lack of maturation, rather a sign that the demand for SPDY and improved performance is strong because people are finding out it's helpful and that Google can be relied upon further to make the web faster.

First of all, SPDY is a properly documented protocol -- there are far more "open" protocols that are documented far worse. It's inside Google's interests to make SPDY adoption as widespread as possible, so it makes sense they would properly document it.

The other part of your argument is based on the fact that it's a binary protocol which makes it less intuitive and impossible/hard to debug when something goes wrong. This is indeed a trade-off chosen by SPDY that makes sense for a lot of the use cases: you're optimizing the protocol for computer, not for humans. You'll need additional debugging tools to find out what's wrong in exchange for better performance.

I'd suggest that too many developers don't understand what goes on over the wire anyway.

It's a documented binary protocol, is open and reasonably easy to understand - spdyshark will help.

One, among many, of Microsoft's 1990's extensions was XMLHttpRequest. Fortunately, although it was (initially) vendor-specific, neither XMLHttpRequest nor SPDY is/was “proprietary” in the IP sense of the term.

No, that's not at all like that. First off, they are proposing them to actually be standards, not just proprietary extensions that no one else can use, like Microsoft was doing.

Second, WebM is actually open source, not proprietary.

Reply on news.ycombinator.com