3 ms·

> Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transp

by pnt12 2y ago

> Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win. As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.

meindnoch 2y ago
>As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior No. It will make things worse, because now lousy drivers are no longer constrained by the bumpy road, so they will become even lousier. Case in point: software is shittier than ever, despite the 100x increase in computer performance since the 90s.
marcosdumay 2y ago
> fixing the bumpy road may help It really wouldn't. Lousy drivers are a way thinner bottleneck than the roads. But it will improve the services where the drivers are good. If the protocol is actually any good (its goals by themselves already make me suspicious it won't be), the well-designed web-apps out there can become even better designed. But it absolutely won't improve the situation people are complaining about.
klabb3 2y ago
> But if this gets improved at the transport layer, seems like a win. What do you mean? TCP and HTTP is already designed for slow links with packet loss, it’s old reliable tech from before modern connectivity. You just have to not pull in thousands of modules in the npm dep tree and add 50 microservice bloatware, ads and client side “telemetry”. You set your cache-control headers and etags, and for large downloads you’ll want range requests. Perhaps some lightweight client side retry logic in case of PWAs. In extreme cases like Antarctica maybe you’d tune some tcp kernel params on the client to reduce RTTs under packet loss. There is nothing major missing from the standard decades old toolbox. Of course it’s not optimal, the web isn’t perfect for offline hybrid apps. But for standard things like reading the news, sending email, chatting, you’ll be fine.

by pnt12 2y ago

meindnoch 2y ago

>As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior No. It will make things worse, because now lousy drivers are no longer constrained by the bumpy road, so they will become even lousier. Case in point: software is shittier than ever, despite the 100x increase in computer performance since the 90s.

marcosdumay 2y ago

> fixing the bumpy road may help It really wouldn't. Lousy drivers are a way thinner bottleneck than the roads. But it will improve the services where the drivers are good. If the protocol is actually any good (its goals by themselves already make me suspicious it won't be), the well-designed web-apps out there can become even better designed. But it absolutely won't improve the situation people are complaining about.

klabb3 2y ago

> But if this gets improved at the transport layer, seems like a win. What do you mean? TCP and HTTP is already designed for slow links with packet loss, it’s old reliable tech from before modern connectivity. You just have to not pull in thousands of modules in the npm dep tree and add 50 microservice bloatware, ads and client side “telemetry”. You set your cache-control headers and etags, and for large downloads you’ll want range requests. Perhaps some lightweight client side retry logic in case of PWAs. In extreme cases like Antarctica maybe you’d tune some tcp kernel params on the client to reduce RTTs under packet loss. There is nothing major missing from the standard decades old toolbox. Of course it’s not optimal, the web isn’t perfect for offline hybrid apps. But for standard things like reading the news, sending email, chatting, you’ll be fine.