Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

Post reply on HN
Print view View original

81–90 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#81

Post by adventured »

zzzcpan wrote: post #52
StefanKarpinski wrote: post #40

Earlier quoted context omitted.

This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting be…

> This attitude is exactly how you make sure that nothing ever changes or improves. On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.

I think you're confusing quantity as being the end result. The quantity is about experimentation. The quality comes as the winning products are refined over time; the low quality products never gain mass traction and are discarded. That's exactly how it should work. These things are complimentary, not mutually exclusive.

That process is how innovation happens quickly. It's also how you frequently discover new things you weren't looking for, which is how a lot of innovation happens (by accident). Rapid iteration is in nearly all cases vastly superior to turtle-speed iteration.

Re: Hello HTTP/2, Goodbye SPDY

#82

Post by drawkbox »

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess.

As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers.

It could be as long lived as XHTML.

I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Protocol designers of the past seemed to have a better long view mixed with simplicity focused on interoperability that you like to see from engineers.

Re: Hello HTTP/2, Goodbye SPDY

#84

Post by venaoy »

striking wrote: post #72
venaoy wrote: post #63

Earlier quoted context omitted.

> 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.

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 i…

> 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.

Re: Hello HTTP/2, Goodbye SPDY

#85

Post by smegel »

drawkbox wrote: post #82

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Pr…

For those slamming HTTP/2.0, how do they rate SPDY?

Re: Hello HTTP/2, Goodbye SPDY

#86

Post by kolev »

drawkbox wrote: post #82

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Pr…

Actually, XHTML was a simplification.

Re: Hello HTTP/2, Goodbye SPDY

#87

Post by drawkbox »

smegel wrote: post #85
drawkbox wrote: post #82

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Pr…

For those slamming HTTP/2.0, how do they rate SPDY?

SPDY was great for Google and allowed them to change and take hold of HTTP/2.

It saved them lots of money I am sure in improved speed but at the trade-off of complexity and minimal adoption of the standard because it wasn't beneficial to everyone. HTTP/2 is a continuation of that effort by Google which I would do if I were them as well probably. But in the end both are not that big of improvements for what they take away.

Of course I use both but I don't think they will last very long until the next, it was too fast and there are large swaths of engineers that do not like being forced into something that has minimal benefits when it could have been a truly nice iteration.

HTTP/2 is really closer to SPDY and I wish they would have just kept it as SPDY for now. Let a little more time go by to see if that is truly useful enough to merge into HTTP/2. HTTP/2 is essentially SPDY from Google tweaked and injected into HTTP/2 which has huge benefits for Google, so I understand where the momentum is coming from.

Google also controls the browser so it is much easier for them to be the lead now on web standards changes. We will have to use it if we like it or not. I don't like the heavy hand that they are using with their browser share, just like Microsoft of older days (i.e plugins killed off, SPDY, HTTP/2, PPAPI, NaCL etc)

Re: Hello HTTP/2, Goodbye SPDY

#88

Post by drawkbox »

kolev wrote: post #86
drawkbox wrote: post #82

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Pr…

Actually, XHTML was a simplification.

Did you close that tag in that textarea from some third party content? If not you're whole view is broken. It was a layer or hopeful standardization that was too hopeful and counted on implementers too much to be exact. It was a nice attempt but was quickly retracted to go to HTML5.

I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implementers, might be the leap that is too hard to make. The best standards are the simple ones that cannot be messed up even by poor implementations. Maybe the standards for protocols developed in the past looked at adoption more as they had to convince everyone to use it, here if you force it you don't need to listen to everyone or simplify, which is a mistake.

While code and products should be exact, over the wire you need to be conservative in what you send and liberal in what you accept in standards and interoperability land.

In another area, there is a reason why things like REST win over things like SOAP, or JSON over XML, it comes down to interoperability and simplicity.

The more simple and interoperable standard will always win, and as standards creators, each iteration should be more simple. As engineers, we have accepted the role of taking complexity and making it simple for others, even other engineers or maybe some junior coder that doesn't understand the complexity. What protocol is the new coder or the junior coder going to gravitate to? The simple one.

Re: Hello HTTP/2, Goodbye SPDY

#89

Post by azakai »

kllrnohj wrote: post #80
azakai wrote: post #36

Earlier quoted context omitted.

We can discuss alternatives to PNaCl, but that isn't really the issue. Even if you have something you believe has no peer at the moment, that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totall…

> that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. What Google is doing with PNaCl is the standards process. Standards start life by being not-standards that someone shipped and enough people liked to make it into a standard. There is nothing wrong here, nothing whatsoever. This is exactly how the process should work. Design-by-committee stan…

While I agree with you that competition is crucial, and without experimentation we will get nowhere, it is worth remembering that IE6 and all of its specific behaviors "won" through "raw competition".

Often things win not through fair competition. For example, WebSQL "won" on mobile because WebKit won on mobile, and WebKit happened to have WebSQL. If WebKit had had, say, the Audio Data API (which it did not), then the Audio Data API would have "won". Neither of those APIs won or would have won on its own merits, but because it was backed by the 800 pound gorilla in the space. (I chose Audio Data as an example because it is not in the same space as WebSQL, i.e. not competing with it, and was a nice API, that failed).

And the problem is that PNaCl will fragment the web, and already has. That's a serious problem - for everyone but Google.

Re: Hello HTTP/2, Goodbye SPDY

#90

Post by icebraining »

Touche wrote: post #71
dragonwriter wrote: post #18

Earlier quoted context omitted.

> Is HTTPS mandatory on HTTP/2 like it was on SPDY? Not in terms of the protocol spec, but most major browser vendors have indicated that they only intend to support HTTP/2 in-browser over TLS connections, so in practice for typical, browser-targeting use cases, it looks like it will, at least initially.

That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.

I'm puzzled, did you miss the announcement? The EFF, Mozilla, and others are creating a CA that will give free certs to everyone: https://letsencrypt.org/
Post reply on HN