4 ms·

Its a shame. Because it would do away with nasty packing strategies like webpack. I always built my go+react apps to avoid webpack,on service start it would sc

Its a shame. Because it would do away with nasty packing strategies like webpack. I always built my go+react apps to avoid webpack,on service start it would scan all the includes from the each entry point and built out a map for each entry point. On request I would push all the dependencies. It was really nice. :(

dhritzkiv 6y ago
While I think webpack is a beast in its complexity, it and other bundlers can/do output based on the strategy you described. It emits entry point bundles, as well as smaller chunks, many of which remain unchanged between releases. All of that gets pushed out. I think it works pretty well.
earthboundkid 6y ago
Push doesn’t work with cache, so that strategy was less efficient than just concatenating everything.
- sanxiyn 6y ago
  Push can work with cache (the article mentions Cache-Digest proposal which directly does this) but it never got implemented for reasons unclear to me.
VWWHFSfQ 6y ago
I guess I never really understood the problem that wasn't just solved by old-school tcp keepalive and pipelining HTTP requests for more assets/files from the CDN
- sanxiyn 6y ago
  HTTP/1.1 pipelining was never useful due to head-of-line blocking and no browsers enabled it by default.
  - bastawhiz 6y ago
    Opera had it enabled. Firefox and Chrome supported it but had it disabled because web servers were too buggy.
  - 1vuio0pswjnm7 6y ago
    It continues to be useful to me. I do not use a browser for pipelining; I wrote simple, custom utilities for generating HTTP. The notion of "HOL blocking" as a "problem" relies on an assumption about the user. Namely, that (a) the user is trying to load resources from multiple sources to display a webpage and (b) the order of the delivery of those resources does not matter. I understand how this fits into Google's business however this is not something I am trying to do. Rather, I routinely download multiple resources from the same source and the order of delivery is important. The simplest example is I am downloading 100 pages from a website; I want page one first and page 100 last, and I do not want page 2 before page 1 is finished. I use pipelining to make 100 HTTP requests over a single TCP connection. It is fast, efficient and has worked reliably for decades.^1 There was a time when server resources were important. For example, opening 100 TCP connections to make 100 HTTP requests might be unduly burdensome on the server. Not to mention each request might complete (or not complete) at a different time. I might receive page 42 before page 21. Then I have to check to make sure each page was received and order them after they all complete. Relative to what I can do, easily, using HTTP/1.1 pipelining, this is a PITA. HTTP/1.1 pipelining has more uses than what the designers of HTTP/2 (Google) might envision. The way I use HTTP/1.1 pipelining, for information retrieval, which only requires a TCP client, e.g., netcat, and a text editor (cf. a third party HTTP/2 library), does not have a "HOL blocking problem". HTTP/1.1 pipelining is not "useless" simply because it does not fit a particular use case involving browsers, internet advertising and commercialisation of the www by those organisations who control browsers and the internet advertising market (and pitch the things they develop in-house like HTTP/2 as "standards"). 1. It is common when the topic of discussion occasionally turns to HTTP/1.1 pipelining to see the follwing factoid repeated: "No browsers have it enabled". There is another factoid we should repeat: "All web servers have it enabled". (This is why I have been using it for so long.) In both cases there may be exceptions. There could be a browser that has pipelining enabled and there are some websites, a very small minority, that have pipelining disabled.
- CyberRabbi 6y ago
  The idea was to eliminate the latency caused by round trips on initial payload. With quic+server push it was theoretically possible to get the server to send you everything necessary to display the requested page with a single request packet (sans subsequent application-transparent flow control packets).
- postalrat 6y ago
  Maybe when resources have dependencies it avoids having to wait for each resource to parse before knowing what else will need to be fetched.
jahewson 6y ago
You can achieve the same thing by concatenation those dependencies in your HTML. It’s equally un-cacheable.
acdha 6y ago
How much have you benchmarked this? If you have a cache-friendly HTML page, any modern browser will load individual resources almost as quickly — and this way you avoid the concern about clogging the pipe with pushed content which is already cached. I get the appeal, having spent plenty of years fighting old browsers back in the day but we're in a much better place now with cheap CDNs and HTTP/2. I've yet to see a project where this time wouldn't be better spent on, for example, using less JavaScript or tuning image/font usage.

dhritzkiv 6y ago

While I think webpack is a beast in its complexity, it and other bundlers can/do output based on the strategy you described. It emits entry point bundles, as well as smaller chunks, many of which remain unchanged between releases. All of that gets pushed out. I think it works pretty well.

earthboundkid 6y ago

Push doesn’t work with cache, so that strategy was less efficient than just concatenating everything.

sanxiyn 6y ago
Push can work with cache (the article mentions Cache-Digest proposal which directly does this) but it never got implemented for reasons unclear to me.

VWWHFSfQ 6y ago

I guess I never really understood the problem that wasn't just solved by old-school tcp keepalive and pipelining HTTP requests for more assets/files from the CDN

sanxiyn 6y ago
HTTP/1.1 pipelining was never useful due to head-of-line blocking and no browsers enabled it by default.
- bastawhiz 6y ago
  Opera had it enabled. Firefox and Chrome supported it but had it disabled because web servers were too buggy.
- 1vuio0pswjnm7 6y ago
  It continues to be useful to me. I do not use a browser for pipelining; I wrote simple, custom utilities for generating HTTP. The notion of "HOL blocking" as a "problem" relies on an assumption about the user. Namely, that (a) the user is trying to load resources from multiple sources to display a webpage and (b) the order of the delivery of those resources does not matter. I understand how this fits into Google's business however this is not something I am trying to do. Rather, I routinely download multiple resources from the same source and the order of delivery is important. The simplest example is I am downloading 100 pages from a website; I want page one first and page 100 last, and I do not want page 2 before page 1 is finished. I use pipelining to make 100 HTTP requests over a single TCP connection. It is fast, efficient and has worked reliably for decades.^1 There was a time when server resources were important. For example, opening 100 TCP connections to make 100 HTTP requests might be unduly burdensome on the server. Not to mention each request might complete (or not complete) at a different time. I might receive page 42 before page 21. Then I have to check to make sure each page was received and order them after they all complete. Relative to what I can do, easily, using HTTP/1.1 pipelining, this is a PITA. HTTP/1.1 pipelining has more uses than what the designers of HTTP/2 (Google) might envision. The way I use HTTP/1.1 pipelining, for information retrieval, which only requires a TCP client, e.g., netcat, and a text editor (cf. a third party HTTP/2 library), does not have a "HOL blocking problem". HTTP/1.1 pipelining is not "useless" simply because it does not fit a particular use case involving browsers, internet advertising and commercialisation of the www by those organisations who control browsers and the internet advertising market (and pitch the things they develop in-house like HTTP/2 as "standards"). 1. It is common when the topic of discussion occasionally turns to HTTP/1.1 pipelining to see the follwing factoid repeated: "No browsers have it enabled". There is another factoid we should repeat: "All web servers have it enabled". (This is why I have been using it for so long.) In both cases there may be exceptions. There could be a browser that has pipelining enabled and there are some websites, a very small minority, that have pipelining disabled.
CyberRabbi 6y ago
The idea was to eliminate the latency caused by round trips on initial payload. With quic+server push it was theoretically possible to get the server to send you everything necessary to display the requested page with a single request packet (sans subsequent application-transparent flow control packets).
postalrat 6y ago
Maybe when resources have dependencies it avoids having to wait for each resource to parse before knowing what else will need to be fetched.

jahewson 6y ago

You can achieve the same thing by concatenation those dependencies in your HTML. It’s equally un-cacheable.

acdha 6y ago

How much have you benchmarked this? If you have a cache-friendly HTML page, any modern browser will load individual resources almost as quickly — and this way you avoid the concern about clogging the pipe with pushed content which is already cached. I get the appeal, having spent plenty of years fighting old browsers back in the day but we're in a much better place now with cheap CDNs and HTTP/2. I've yet to see a project where this time wouldn't be better spent on, for example, using less JavaScript or tuning image/font usage.