Are you really implying it doesn’t? So many Web “best practices” are working around the limitations of HTTP and the web 1.0 legacy we still carry around. See:
1. Concatenating resources (1 CSS file is worlds better than 50. Need it be?)
2. Inlining resources (see above)
3. Scaling, yes, is very hard! Look at all the techniques for deploying updates to web apps without breaking users' experiences.
I’m not saying HTTP2.0 will or won't solve all these problems, but clearly there is much room for improvement over HTTP 1
1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well.
2. Sure.
3. This has nothing to do with the protocol.
I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.
Comments
I'm sorry, but are you really implying that HTTP doesn't scale?
Are you really implying it doesn’t? So many Web “best practices” are working around the limitations of HTTP and the web 1.0 legacy we still carry around. See:
1. Concatenating resources (1 CSS file is worlds better than 50. Need it be?)
2. Inlining resources (see above)
3. Scaling, yes, is very hard! Look at all the techniques for deploying updates to web apps without breaking users' experiences.
I’m not saying HTTP2.0 will or won't solve all these problems, but clearly there is much room for improvement over HTTP 1
Am I implying that it does? Yes.
1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well.
2. Sure.
3. This has nothing to do with the protocol.
I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.
SPDY wouldn't be a thing if HTTP were sufficient at the massive scales we're talking here.