3 ms·

The correct answer is that HTTP/2 has to do this because Google is unable to show you a simple search box without making over a dozen HTTP requests. Their more

The correct answer is that HTTP/2 has to do this because Google is unable to show you a simple search box without making over a dozen HTTP requests. Their more involved properties require dozens to even hundreds of requests in order to perform complex tasks like showing a list of plain text posts. And, of course, they can't possibly impose any kind of discipline on the way they do things, so instead the entire internet has to change to accommodate them.

FooBarWidget 12y ago
It's so easy to blame everything on Google/Microsoft/$OTHER_BLACK_SHEEP being stupid. I don't know how many websites you've been to, but a large number of them perform hundreds of requests, not just Google. The modern web is full of images, CSS, webfonts, dynamically loaded Javascript, mashups and other things, each which require one or more HTTP requests. Having lots of requests has been the reality for a large part of the web for a number of years now.
zaphar 12y ago
My plaintext no animations statically generated site does 5 connections to load the content. http://jeremy.marzhillstudios.com http://jeremy.marzhillstudios.com Now I could optimize that even more by inlining everything with data-inline: but that would impact caching code and be strictly worse for the network. A property from google even websearch has fancy transitions and animations and dynamic content. And Google has every incentive to limit the number of connections to their page. When I worked there I worked on some of those technologies specifically to avoid too many connections. Blaming Google for not being disciplined enough disregards their economic incentives to be disciplined enough. They invested a lot of energy in this before SPDY came out. There comes a time where you just have to recognize that the protocol is fighting against you and either give up or evolve the protocol.
twistedpair 12y ago
Google created GWT which uses every trick under the sun to reduce connection counts. I use it on my sites and if you don't let your web property devolve into a bolt-on JS mire (as many large sites do, i.e. Borders recently made 248 requests to load), you can load the page/app in 4 requests. (1) index.html, (2) app.nocache.js (3) A56284CFC0D680C7DBA0F93CA9AE8F75.cache.js (cache fragment for given page/state) (4) XHR for page data/state to display Now, if you've got some CSS and minor images/fonts, these can be an your options request (5) resource bundle. On many Google properties, (2 and 5) are inlined into (1). The take away? These technologies and frameworks have been out there for a long time (8 years in the case of GWT), so you don't have to make hundreds of requests if you're disciplined. I can only assume Google has thrown in the towel trying to get script kiddies to ever be disciplined.
wpietri 12y ago
Exactly right. Humans only exist to serve their tools. No, wait a sec. That doesn't sound right. Could it be that our tools exist to serve humans? And that rather than putting effort into accommodating ourselves to the limitations of our current tools, we should instead put our effort into making tools that work the way we want? Nah, sounds crazy. If HTTP/1 was good enough for my grand-dad, it's good enough for me.

FooBarWidget 12y ago

It's so easy to blame everything on Google/Microsoft/$OTHER_BLACK_SHEEP being stupid. I don't know how many websites you've been to, but a large number of them perform hundreds of requests, not just Google. The modern web is full of images, CSS, webfonts, dynamically loaded Javascript, mashups and other things, each which require one or more HTTP requests. Having lots of requests has been the reality for a large part of the web for a number of years now.

zaphar 12y ago

My plaintext no animations statically generated site does 5 connections to load the content. http://jeremy.marzhillstudios.com http://jeremy.marzhillstudios.com Now I could optimize that even more by inlining everything with data-inline: but that would impact caching code and be strictly worse for the network. A property from google even websearch has fancy transitions and animations and dynamic content. And Google has every incentive to limit the number of connections to their page. When I worked there I worked on some of those technologies specifically to avoid too many connections. Blaming Google for not being disciplined enough disregards their economic incentives to be disciplined enough. They invested a lot of energy in this before SPDY came out. There comes a time where you just have to recognize that the protocol is fighting against you and either give up or evolve the protocol.

twistedpair 12y ago

Google created GWT which uses every trick under the sun to reduce connection counts. I use it on my sites and if you don't let your web property devolve into a bolt-on JS mire (as many large sites do, i.e. Borders recently made 248 requests to load), you can load the page/app in 4 requests. (1) index.html, (2) app.nocache.js (3) A56284CFC0D680C7DBA0F93CA9AE8F75.cache.js (cache fragment for given page/state) (4) XHR for page data/state to display Now, if you've got some CSS and minor images/fonts, these can be an your options request (5) resource bundle. On many Google properties, (2 and 5) are inlined into (1). The take away? These technologies and frameworks have been out there for a long time (8 years in the case of GWT), so you don't have to make hundreds of requests if you're disciplined. I can only assume Google has thrown in the towel trying to get script kiddies to ever be disciplined.

wpietri 12y ago

Exactly right. Humans only exist to serve their tools. No, wait a sec. That doesn't sound right. Could it be that our tools exist to serve humans? And that rather than putting effort into accommodating ourselves to the limitations of our current tools, we should instead put our effort into making tools that work the way we want? Nah, sounds crazy. If HTTP/1 was good enough for my grand-dad, it's good enough for me.