9 ms·

This comment is not specifically about quic, which I believe is a solid idea and would love to see used and supported more, but about the topic of requiring sup

This comment is not specifically about quic, which I believe is a solid idea and would love to see used and supported more, but about the topic of requiring super fast connections to do things that really shouldn't need them. Accessing a page where all useful information I am interested in is text, should not require a new protocol developed by genius engineers to work without delay. If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted. Why isn't that the case? Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don't need. I am not saying "don't invent new protocols". But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards. https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm If we don't think about this, then neither QUIC, nor QUIC2 or REALLY_QUIC will save us from being wading through a pool of molasses slow crap. Because inevitably, following each techical improvement that could makes our stack faster, is an even bigger pile of bloat that drags it down again.

delusional 5y ago
You already know this, but the "mountains of extraneous garbage" is the content. The text you care about is just there to make you download and execute the rest. quic is not needed to give you the text you want. It's needed to deliver the actual content, the ads.
- Nemi 5y ago
  I agree that it is a greek tragedy that it always comes to this, but this is just the market’s way of monetizing the medium. This is how it happens. We used to sit through 20 minutes(!) of commercials every hour for tv content. Now we download one or two magnitudes more data than is required so that the content we actually want is “free”. Efficient markets will always devolve to this unfortunately. At least this (compared to unskippable commercials of past) I can bypass looking at.
candiodari 5y ago
OTOH, QUICK will mean UDP with per-stream flow control gets through every corporate firewall on the planet in 5 or so years. Hurray!
- akyoan 5y ago
  Why would they do that when HTTP1.1 is perfectly fine and available? That will be the explanation, I’m not too optimistic.
- goodpoint 5y ago
  Making firewalls even less effective at mitigating attacks.
  - candiodari 5y ago
    Given that connecting to technical docs or ssh is considered an "attack" by half the people hiring consultants, that will be a very good thing indeed.
jbergstroem 5y ago
You have $N hosts and CDN's in the world and $M web developers. If you can affect $N that's a pretty big win for every web developer, not just the one that has enough experience to understand how and why css/js frameworks are ultimately as "easy and fast" as the marketing page said. I'm sure the trend of web performance and best practices will improve as tooling to showcase these issues get easier and better by the day; but making the car more efficient is a different problem to a wider, more stable and ultimately faster motorway.
- usrbinbash 5y ago
  There are cities that tried to solve the problems of having constant traffic congestion on all 4 lanes by demolishing buildings and building 2 more lanes. The result: traffic congestion on 6 lanes.
  - rjbwork 5y ago
    A fairly good point. Modern adtech is kind of the induced demand of internet bandwidth - that is, when new bandwidth is available, adtech will grow to fill that bandwidth. I guess this is also analogous to the fact that our computers are WAYYY faster now than 20 years ago, but user experience of application performance is roughly similar due to the tools used to build applications eating up a lot of that performance to make it easy to build them (electron, WPF, QT, browsers, etc).
  - Nullabillity 5y ago
    If congestion stayed the same then ~1.5x (slightly less in reality, since each lane does introduce some overhead) the people were able to get to where they wanted (still a win!) or there was a bottleneck somewhere else in the system (so go address that as well!).
    - distances 5y ago
      Interestingly by Braess's paradox adding more lanes can increase congestion, and removing lanes can speed up the traffic. https://en.wikipedia.org/wiki/Braess%27s_paradox https://en.wikipedia.org/wiki/Braess%27s_paradox
unbanned 5y ago
>should not require a new protocol developed by genius engineers to work without delay Why not?
- christophilus 5y ago
  He explained why. Visit the old Bob Dole website, then visit a 2021 candidate’s website. The problem isn’t the protocol. It’s the internet obesity crisis.
  - unbanned 5y ago
    Why would you not want experts designing a protocol of such reach and significance?
    - christophilus 5y ago
      I don’t know if you’re deliberately trolling. In the off chance you’re not, I suggest that you took the entirely wrong takeaway from the OP, and I suggest rereading. He never said experts shouldn’t design protocols, and nothing like that was anywhere near the point.
jefftk 5y ago
> it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s I think you have an overly rosy view of the time. Yes, some things were fast, especially if you had an unusually good connection, but the average person's experience of the internet was much slower and less reliable.
- 5e92cb50239222b 5y ago
  I used dial-up until around 2010. Yes, pages were loading pretty much forever, but once it's been loaded, it was fast (and I always use mid-level hardware at best). I was used to opening up to 100 pages on my shitty Celeron with 128 MBs of RAM with Opera 9 (I think). Because dial-up is paid by the minute and you really have to open as many pages as possible and read them all later. It worked just fine. Then the fat client/SPA devolution happened; you know the rest.
austincheney 5y ago
The web is an arms race. The bloat and slowness is generally due to incompetence. On one hand it’s merchandising stalking users with poorly written spyware and on the other hand the technology is dictated by the lowest common denominator of developers who cannot perform without monumental hand holding. Does the end user really want or prefer the megs of framework abstraction? No, that’s immature trash from developers insecure about their jobs. This is the standard of practice and it isn’t going away. In hiring it’s seen as a preference as increased tool proliferation can qualify higher wages. The only way that’s going to get better is by moving to an alternate platform with more challenging technical concerns than populating content. With IPv6 and gigabit internet to the house becoming more common in the US there is less and less reason to require web servers, data centers, and other third party concerns. These are incredibly expensive and so long as the platform becomes progressively more hostile to their users emerging alternatives with superior on-demand capabilities will become more appealing.
- specialist 5y ago
  Yes and: > The bloat and slowness is generally due to incompetence. I'm sure this is true. I'm also reminded of "office automation". Conventional wisdom was that new technologies would reduce the use of paper. However, for decades, paper usage went up, and it took a long time for the reduction to happen. Curious, no? Was increased paper usage an instance of Jevons Paradox? https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox I have questions. So then why did paper usage eventually plummet? Given long enough time frame, is Jevons Paradox a phase? 150 years after Jevons book The Coal Question, coal consumption is finally tanking. Decades after the start of data processing and office automation, paper usage finally tanked. Is this generalizable? Clearly software bloat (and by extension web page bloat) are catalyzed by better tools. Like the democratization of word processing (et al) begat more paper usage, IDEs (et al) begat more code production. If there is a downside slope to Jevons "rebound effect" (efficiency -> lower cost -> higher consumption), what could it look like for software bloat? What are some possible causes? For coal and paper, it was displacement by even cheaper alternatives. What's cheaper than large, slow web pages? Or conversely, how do we raise the cost of that bloat? Making a huge leap of reasoning: My optimistic self hopes that the key resource is attention (people's time). Social media values each person's eyeballs at $100/yr (or whatever). So all the nominal costs of all those bloated web pages is pretty cheap. My hope is the displacement of software bloat will be somehow related to maximizing people's cognitive abilities, making better use of attention. So replace web surfing, doom scrolling, and the misc opiates of the masses with whatever's next. This hope is strongly rooted in Clay Shirky's works Cognitive Surplus and Here Comes Everyone. Thanks for reading this far. To wrap this up: I regard software bloat as a phase, not inevitable. I imagine a futureperfect media ecosystem not dependent on ad supported biz models, the primary driver for web page bloat. I have no idea if people smarter than me have studied the tail end of Jevon's Paradox. Or even how much predictive power the Paradox has at all. I have no idea what the displacement may look like. Maybe patronage and subscriptions. Or maybe universal basic income, so amateurs can self produce and publish; versus "platforms" exploiting user generated content and collaborative editing. A bit of a scrambled thesis, I know. I'm writing to understand, sound out a new idea. Thanks for your patience.
tlamponi 5y ago
> If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted. I mean no, but it can be unreasonable to expect that physical limits get beaten if you have in mind that some people just have a few hundred to a thousand KM between their computer and the server they access. E.g., in my hometown I may get latencies of 200 ms and more to a few sites, especially simpler ones that have no CDN but are a single server on the other end of the world. Don't get me started if I'm travelling between Vienna and South Tyrol using the train, in some parts (cough Germany) the internet is really spotty and latency spikes up to 10 to 20s are (sadly) rather normal for a few minutes here and there. Now, with HTTP 1.1 over TCP and TLS involved the setup time already gets me to almost a second of wait time (more than the few tens of ms my finger needs to leave the Enter key) in the former setup and in the latter I may need 30 to 60s, or it even just times out when travelling by train and being in a bad spot, connectivity wise. QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times (none) compared to TCP (even with TCP fast-open). So simple websites can profit too from QUIC, initial load time can get reduced a lot, browsing them is finally doable also on remote, spotty connections. Also, I happen to develop applications that are delivered as web app, they just tend to acquire a certain complexity even if one tries to stay simple, so loading that faster even if nothing is already cached is a welcome thing to me. Bloated page still will be slow, sure faster than with HTTP 1.1 but still slow, and I definitively would like to see that getting improved, but that's not really related to the issues that QUIC improves on, as simple websites win too when using it; it's just less noticeable there if you already have a somewhat OK connection. In summary: Why not invent a new protocol if you can significantly reduce overhead for everyone, especially if it can coexist with the simple and established one.
- deepstack 5y ago
  >QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times compared to TCP. hmmm abit skeptical on the less round-times. Are the all the round-times in TCP to ensure the integrity of the connection. With UPD it is my understanding that no confirmation of receiving packet is issued. So a server can send out a signal, but never can be sure if the client got it. I can see it can be great for multiplexing/broadcasting, but the switch the whole http protocol over like this, I can't imagine there won't be tons integrity and security issues.
ignoramous 5y ago
> It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where A good solution could have been AMP: https://amp.dev/ https://amp.dev/ > mostly to spy on me If only AMP was not beholden to an adcorp.
- the8472 5y ago
  Isn't the first thing AMP does pull in some javascript that was required to render the page? I recall there being some relatively long delay showing an empty page if you had some stuff blocked because it was waiting for a fallback. Or maybe that was some other google thing that did it. That's exactly the opposite of HTML first with small sprinkles of CSS and JS.
  - ignoramous 5y ago
    Well, I meant, a web-standard like AMP aimed at clamping down webpage-obesity would be nice (instead of AMP).
    - the8472 5y ago
      I think most of that could be achieved by a bunch of CSP rules that disable various features. No frames, no 3rd-party js, various request types restricted to same-site and data: URIs. Don't grant sandbox: allow-same-origin and the site will be a unique origin on each visit, thus effectively disabling cookies. So it's already possible to achieve quite restricted subsets of what a website can do. The issue is agreeing on what subset is useful enough for many sites.
throwawaylinux 5y ago
Google wants to send you these blobs though, which is (one of the reasons) why they develop faster protocols.
dm33tri 5y ago
Sometimes when I have a very limited connection on mobile, nothing helps the web and no pages would load over https, even if it's just plain HTML. And if the connection drops, then it almost certainly won't recover and full page reload is necessary. Other protocols may work much better in such conditions, for example popular messengers can send and receive text, metadata and blurry image previews just fine. In some cases even voice calls are possible, but not a single website would load ever. I think HN crowd won't notice the changes. I hope that the protocol would improve experience for smartphone users without reliable 4G connection.
- josefx 5y ago
  > for example popular messengers can send and receive text, Your messenger isn't sending tens of megabytes for every message. > metadata and blurry image previews just fine. One might wonder why they don't just send the 4 MB JPEGs instead of those down scaled to hell previews if they work so well. > . In some cases even voice calls are possible Not only kilobytes of data, but kilobytes of data where transmission errors can be completely ignored. I have been in enough VoIP calls to notice how "well" that works in bad conditions. Everything points to putting websites on a diet being the correct solution. > And if the connection drops, then it almost certainly won't recover and full page reload is necessary. I would consider that a browser bug. No idea why the connection wont just timeout and retry by itself.
  - Dylan16807 5y ago
    > Everything points to putting websites on a diet being the correct solution. It would help a lot but it's not a full solution. You also need to stop TCP from assuming that every lost packet is because of congestion, or it will take a slow connection and then underload it by a huge factor.
- dangerbird2 5y ago
  Yeah, one of the major uses of http/3 is that it can gracefully handle connection interruptions and changes, like when you switch from wifi to mobile, without having to wait for the tcp stream to timeout. That's a huge win for both humongous web apps and hackernews' idealized static webpage of text and hyperlinks.
msy 5y ago
The primary purpose of the web is now an app delivery platform & VM execution environment, not text delivery.
- Cthulhu_ 5y ago
  Anecdotal, most of my internet use is still finding and reading text based information. ...I mean it's to build a web application, but that's different.
- wolf550e 5y ago
  That is correct but irrelevant. When I reach a landing page that mainly has text content (whether it's a news article, a blog post, a company's "about us" or a product's features list/matrix or something else), the page should load fast. My browsers shouldn't need to make 100 network connections and download megabytes to display a thousand words of text and some images. It should be about 1 network connection and maybe dozens of kilobytes (for images). We are not complaining about the web version of productivity apps like email, spreadsheets, project management, etc. loading slowly. But a newspaper article should load faster than a social media feed, and often they don't.
javajosh 5y ago
Next you'll be telling people that rather than rent storage units to store all their extra stuff, and then build an app to track all of that stuff, to just not buy so much stuff in the first place. If you generalize this type of dangerous advice, then what happens to the American economy? The same applies to websites: if you don't add all that great good stuff into every page, then what happens to the programmer economy?[1] [1] Although satire is dead, killed by people actually espousing extreme views on the internet, I still indulge but am forced to explicitly tell the reader: this is ridiculous satire. Of course we should solve the root of the problem and not invent/adopt technology that enables our bad habits.
comeonseriously 5y ago
> Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don't need. But that is how 75% of the people reading this make their living...
- posix_me_less 5y ago
  Which is why putting that observation here on HN is so important. We can do something about it!
onion2k 5y ago
But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards. I've been building web stuff since the 90s. Your memory of what it was like is flawed. Sites were slow to load. People complained about images because they took a while to load, and as soon as they completed the page jumped down and you lost your place. Moving from one page to another page on the same site required throwing all the HTML away and starting over, even in a web app like an email client (MSFT literally invented XMLHttpRequest to solve that). The HTML content itself was bloated with styles and font tags and table layouts. Often a tiny article would weigh in at 50KB just because it had been created in DreamWeaver or Hotmetal or something and the code was horrible. Thr web didn't feel fast back then. It was hellishly slow. I had perf budgets to get sites loaded in under 8s (and that was just measuring the time to a DOMContentLoaded event, not the same as today's Core Web Vitals idea of loaded). There's no doubt that the web is, in many places, bloated to shit. It's not worse though. It's significantly better. It's just that there's more work to be done.
- usrbinbash 5y ago
  >It's significantly better. Its not better if the only thing that keeps it afloat is the fact that broadband is ubiquitous by now (and that isn't even true for most of the world), and hardware got alot better. The main difference is that many people started using the web after the gamification and bloatation took over, so they are used to adbanners flying in, random videos which start playing, and phone batteries going flat just by looking at a news article. > It's just that there's more work to be done. But is that extra work necessary? Look at this threads page on HN. It loads 402 kb worth of content: the html, a tiny amount of JS that isn't even minified (and doesn't have to because its so slim), a small css file, 3 small gifs and the favicon. That's it. That's all the network-load required to display a usable, information-dense, not hard to look at and performant experience.
jameshart 5y ago
Can you be specific - Which sites are you actually complaining about here? This site, which we're on, delivers pages of comments (this very comment thread is around 50K of comment text) almost instantly. The Washington Post homepage loads in 600ms for me. 20K of text. Images load within about another 500ms. Their lead article right now is one of those visual feature ones with animations that trigger on scroll, so after the text first appears after 600ms, it takes a second or so longer for the layout to finish. But a routine text article page, I have a scrollable, readable text view within 500ms. CNN.com, a fraction slower, for a little less text, but a lot more pictures. When I click into one of their articles, within a few seconds, it starts streaming me 1080p video of their news coverage of the article. Imagine that on your 'fast functional 90s and early 00s' web. Or let's pick a technical resource. go.dev's landing page? No noticeable delay in loading for me, and that page has an embedded form for trying out Go code. Or reactjs.org, say? Loads up in 200ms for me, and then subsequent navigations on site among documentation pages take about 60ms. How about a government resource? irs.gov? The homepage maybe loads a little slower than I'd like, but FAQ pages are pretty responsive for me, with text appearing almost as soon as I've clicked the link. I'm not cherrypicking, these were the first few websites that came to mind to test to see if things are really as bad as you're portraying. And my impression is... you know? It's not that bad? I am not arguing that there aren't bad sites out there, but we need to stop pretending that the entire world has gone to hell in a handcart and the kids building websites today don't care about optimization. Substantive websites deliver substantive content efficiently and effectively, with a level of functionality and visual flair that the 90s/00s web could only have dreamed of.
- password4321 5y ago
  Is this with or without blocking ads?
  - jameshart 5y ago
    I run an adblocker, like about 27% of web users, sure. Do you get substantively different experiences on those sites if you don't?
kobalsky 5y ago
regardless of website bloat, tcp is pure garbage when dealing with even minimal packet loss and it has always contributed to the crappy feeling that mobile connections have. if something doesn't start loading in 5 seconds and you are still giving it time without jumping up and down, tcp gave you stockholm syndrome. I'm not familiar with quic so I don't know how to feel about it, but we are in dire need of an alternative that doesn't require reimplementing the good parts of tcp over udp like every game and communication apps in the world do.
- howdydoo 5y ago
  Are you alluding to SCTP/DCCP? Or is there some other protocol I don't know about?
- ReactiveJelly 5y ago
  I think QUIC is gonna be it, at least for the next 10 years. It has unreliable, unordered datagrams, and a huge number of TCP-like streams, all wrapped in the same TLS'd connection. When I look at QUIC, I see old TCP protocols like IRC and telnet coming back. The difficulty of encryption pushed many applications into HTTPS so they could stay safe, even though HTTPS isn't a perfect fit for every app. With QUIC saying "You're as safe as possible and you have basically a UDP and TCP portal to the server, have fun", I think we'll see some custom protocols built / rebuilt on QUIC that were lying dormant since the age when encryption was optional. For instance, multiplayer games could probably just use QUIC as-is. Send the real-time data over the datagrams, and send the chat messages and important game state over the streams. Instead of some custom game communications library, and instead of connecting TCP and UDP to the same server, one QUIC library and one QUIC connection. Now it's within the reach of a solo indie developer who wants to focus on their game-specific netcode, and not on re-inventing networking ideas.
  - jayd16 5y ago
    Does the HTTP/3 spec provide access to UDP-like (non-retransmitted) requests? It looks like this might need another extension?
hdjjhhvvhga 5y ago
> If we don't think about this Actually, in this case "we" means Google and a few other big companies whose aims are not the same as ours - they are the ones in charge. Sure, at times it happens that our interests are somewhat aligned (like page load times) but only as far as it serves them. For Google, a page without their code like ads/analytics is pretty much useless; for us, it's more useful because it doesn't track us and loads faster. So yes, while they continue doing some work in that respect, I expect it will actually go worse with time as they are focused on average consumer bandwidth in the USA. Once G5 is well entrenched and broadband/fiber gets even faster, we can expect even more bloat on websites and there is not much "we" (=users and developers) can actually do about it.
fiedzia 5y ago
The reason is that a) if it doesn't look good, most people will not take it seriously and b) you must have ads and tracking of user activity. What I really don't get is why bare html looks so awfully today and you have to add tons of js and css to get something acceptable.
- usrbinbash 5y ago
  > and you have to add tons of js and css to get something acceptable No we don't. As I have written before in this topic, HN is the perfect example. It pulls in a small css and js file, both of which are so slim, they don't even require minifying. The resulting page is small, looks good, is performant and most importantly does its jobs. We don't need megabytes worth of cruft to display a good looking page.
  - fiedzia 5y ago
    > HN is the perfect example. It pulls in a small css and js file, both of which are so slim, they don't even require minifying. The resulting page is small, looks good It looks good for technical people. It does not look good for others.
    - usrbinbash 5y ago
      Pretty sure my mum would love for her recipe websites to fit the entire recipe on screen at once, instead of having to scroll over a gigantic font, interlaced with 4+ irrelevant pictures of smiling people holding fruits and 2 ad banners, canceling the ubiquitous "we use cokkies balabla.." popup and maybe some full-page ad-overlay. I am also sure she would love these selfsame pages to load instantly when shes accessing them via her old cell phone at my uncles house where reception is bad and the device has to revert to 3G. No, "other" people don't want bloat, tons of adds and "clever designs" (aka. a huge useless picture-banner that contains zero information) either.
      - fiedzia 5y ago
        Great examples. Downloaded size for top 3 sites for recipes: https://www.bbcgoodfood.com/ https://www.bbcgoodfood.com/ - 12MB https://www.jamieoliver.com/ https://www.jamieoliver.com/ - 4.3MB https://www.deliciousmagazine.co.uk/ https://www.deliciousmagazine.co.uk/ - 8.4MB It seems their users didn't wanted them to be so barebone. I am not saying people want bloat, but they won't accept HN-style simplicity. What I'd like to have is good looking sites with no CSS at all, just make them acceptable by default, and a lot of this bloat will simply go away.
hdjjhhvvhga 5y ago
Oh this is hilarious: > The tech lead for Google's AMP project was nice enough to engage us on Twitter. He acknowledged the bloat, but explained that Google was "resource constrained" and had had to outsource this project > This admission moved me deeply, because I had no idea Google was in a tight spot. So I spent a couple of hours of my own time making a static version of the AMP website. . . > By cutting out cruft, I was able to get the page weight down to half a megabyte in one afternoon of work. This is eight times smaller than the original page. > I offered my changes to Google free of charge, but they are evidently too resource constrained to even find the time to copy it over.
deleted 5y ago
[deleted]
ReactiveJelly 5y ago
> It's sad that we need this. No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually. Look back at the small site hosted in Bangalore - That's an Indian version of me. A hacker whose projects can't run on self-hosted Wordpress, who only bought a VPS because their home ISP is not reliable. With HTTP/1, most of America can't load their site, it times out. With HTTP/2, it takes 2,500 ms. With HTTP/3, it takes 1,000. A _petty_ software upgrade allows this imagined Indian blogger to gain an audience on _another continent_ without buying more servers, without using a CDN, and without taking advertising deals to afford more stuff. You know 3 things I hate about the web? Advertisements, CDNs, and having to buy servers. I promise this is purely geographical, not political - How often do you connect to servers outside the USA and Europe? I mean trading packets with a computer. YouTube uploads don't count because they have a CDN. For me, the answer is "almost never". The Internet is supposed to be global, but computers are made of matter and occupy space, so connections to nearer servers are still better, and they always will be. But QUIC makes the far-away connections a little less bad. That is a good thing.
- combyn8tor 5y ago
  A CDN solves those issues and is significantly faster than HTTP3 in your use case... why the hate for them? The centralised aspect?
  - anonymoushn 5y ago
    TCP head-of-line blocking is a huge problem. Almost nothing should use TCP. I am happy if people use CDNs but even happier if people use HTTP/3.
- Dylan16807 5y ago
  > With HTTP/1, most of America can't load their site, it times out. That shouldn't happen. Do you have a real site in mind there? > No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually. That can be true at the same time as "it's sad that we need this"
Chris2048 5y ago
Monetisation. The old internet didn't have enough rent-seekers gatekeeping the content. Even Wikipedia begs for money it doesn't need.

delusional 5y ago

You already know this, but the "mountains of extraneous garbage" is the content. The text you care about is just there to make you download and execute the rest. quic is not needed to give you the text you want. It's needed to deliver the actual content, the ads.

Nemi 5y ago
I agree that it is a greek tragedy that it always comes to this, but this is just the market’s way of monetizing the medium. This is how it happens. We used to sit through 20 minutes(!) of commercials every hour for tv content. Now we download one or two magnitudes more data than is required so that the content we actually want is “free”. Efficient markets will always devolve to this unfortunately. At least this (compared to unskippable commercials of past) I can bypass looking at.

candiodari 5y ago

OTOH, QUICK will mean UDP with per-stream flow control gets through every corporate firewall on the planet in 5 or so years. Hurray!

akyoan 5y ago
Why would they do that when HTTP1.1 is perfectly fine and available? That will be the explanation, I’m not too optimistic.
goodpoint 5y ago
Making firewalls even less effective at mitigating attacks.
- candiodari 5y ago
  Given that connecting to technical docs or ssh is considered an "attack" by half the people hiring consultants, that will be a very good thing indeed.

jbergstroem 5y ago

You have $N hosts and CDN's in the world and $M web developers. If you can affect $N that's a pretty big win for every web developer, not just the one that has enough experience to understand how and why css/js frameworks are ultimately as "easy and fast" as the marketing page said. I'm sure the trend of web performance and best practices will improve as tooling to showcase these issues get easier and better by the day; but making the car more efficient is a different problem to a wider, more stable and ultimately faster motorway.

usrbinbash 5y ago
There are cities that tried to solve the problems of having constant traffic congestion on all 4 lanes by demolishing buildings and building 2 more lanes. The result: traffic congestion on 6 lanes.
- rjbwork 5y ago
  A fairly good point. Modern adtech is kind of the induced demand of internet bandwidth - that is, when new bandwidth is available, adtech will grow to fill that bandwidth. I guess this is also analogous to the fact that our computers are WAYYY faster now than 20 years ago, but user experience of application performance is roughly similar due to the tools used to build applications eating up a lot of that performance to make it easy to build them (electron, WPF, QT, browsers, etc).
- Nullabillity 5y ago
  If congestion stayed the same then ~1.5x (slightly less in reality, since each lane does introduce some overhead) the people were able to get to where they wanted (still a win!) or there was a bottleneck somewhere else in the system (so go address that as well!).
  - distances 5y ago
    Interestingly by Braess's paradox adding more lanes can increase congestion, and removing lanes can speed up the traffic. https://en.wikipedia.org/wiki/Braess%27s_paradox https://en.wikipedia.org/wiki/Braess%27s_paradox

unbanned 5y ago

>should not require a new protocol developed by genius engineers to work without delay Why not?

christophilus 5y ago
He explained why. Visit the old Bob Dole website, then visit a 2021 candidate’s website. The problem isn’t the protocol. It’s the internet obesity crisis.
- unbanned 5y ago
  Why would you not want experts designing a protocol of such reach and significance?
  - christophilus 5y ago
    I don’t know if you’re deliberately trolling. In the off chance you’re not, I suggest that you took the entirely wrong takeaway from the OP, and I suggest rereading. He never said experts shouldn’t design protocols, and nothing like that was anywhere near the point.

jefftk 5y ago

> it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s I think you have an overly rosy view of the time. Yes, some things were fast, especially if you had an unusually good connection, but the average person's experience of the internet was much slower and less reliable.

5e92cb50239222b 5y ago
I used dial-up until around 2010. Yes, pages were loading pretty much forever, but once it's been loaded, it was fast (and I always use mid-level hardware at best). I was used to opening up to 100 pages on my shitty Celeron with 128 MBs of RAM with Opera 9 (I think). Because dial-up is paid by the minute and you really have to open as many pages as possible and read them all later. It worked just fine. Then the fat client/SPA devolution happened; you know the rest.

austincheney 5y ago

The web is an arms race. The bloat and slowness is generally due to incompetence. On one hand it’s merchandising stalking users with poorly written spyware and on the other hand the technology is dictated by the lowest common denominator of developers who cannot perform without monumental hand holding. Does the end user really want or prefer the megs of framework abstraction? No, that’s immature trash from developers insecure about their jobs. This is the standard of practice and it isn’t going away. In hiring it’s seen as a preference as increased tool proliferation can qualify higher wages. The only way that’s going to get better is by moving to an alternate platform with more challenging technical concerns than populating content. With IPv6 and gigabit internet to the house becoming more common in the US there is less and less reason to require web servers, data centers, and other third party concerns. These are incredibly expensive and so long as the platform becomes progressively more hostile to their users emerging alternatives with superior on-demand capabilities will become more appealing.

specialist 5y ago
Yes and: > The bloat and slowness is generally due to incompetence. I'm sure this is true. I'm also reminded of "office automation". Conventional wisdom was that new technologies would reduce the use of paper. However, for decades, paper usage went up, and it took a long time for the reduction to happen. Curious, no? Was increased paper usage an instance of Jevons Paradox? https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox I have questions. So then why did paper usage eventually plummet? Given long enough time frame, is Jevons Paradox a phase? 150 years after Jevons book The Coal Question, coal consumption is finally tanking. Decades after the start of data processing and office automation, paper usage finally tanked. Is this generalizable? Clearly software bloat (and by extension web page bloat) are catalyzed by better tools. Like the democratization of word processing (et al) begat more paper usage, IDEs (et al) begat more code production. If there is a downside slope to Jevons "rebound effect" (efficiency -> lower cost -> higher consumption), what could it look like for software bloat? What are some possible causes? For coal and paper, it was displacement by even cheaper alternatives. What's cheaper than large, slow web pages? Or conversely, how do we raise the cost of that bloat? Making a huge leap of reasoning: My optimistic self hopes that the key resource is attention (people's time). Social media values each person's eyeballs at $100/yr (or whatever). So all the nominal costs of all those bloated web pages is pretty cheap. My hope is the displacement of software bloat will be somehow related to maximizing people's cognitive abilities, making better use of attention. So replace web surfing, doom scrolling, and the misc opiates of the masses with whatever's next. This hope is strongly rooted in Clay Shirky's works Cognitive Surplus and Here Comes Everyone. Thanks for reading this far. To wrap this up: I regard software bloat as a phase, not inevitable. I imagine a futureperfect media ecosystem not dependent on ad supported biz models, the primary driver for web page bloat. I have no idea if people smarter than me have studied the tail end of Jevon's Paradox. Or even how much predictive power the Paradox has at all. I have no idea what the displacement may look like. Maybe patronage and subscriptions. Or maybe universal basic income, so amateurs can self produce and publish; versus "platforms" exploiting user generated content and collaborative editing. A bit of a scrambled thesis, I know. I'm writing to understand, sound out a new idea. Thanks for your patience.

tlamponi 5y ago

> If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted. I mean no, but it can be unreasonable to expect that physical limits get beaten if you have in mind that some people just have a few hundred to a thousand KM between their computer and the server they access. E.g., in my hometown I may get latencies of 200 ms and more to a few sites, especially simpler ones that have no CDN but are a single server on the other end of the world. Don't get me started if I'm travelling between Vienna and South Tyrol using the train, in some parts (cough Germany) the internet is really spotty and latency spikes up to 10 to 20s are (sadly) rather normal for a few minutes here and there. Now, with HTTP 1.1 over TCP and TLS involved the setup time already gets me to almost a second of wait time (more than the few tens of ms my finger needs to leave the Enter key) in the former setup and in the latter I may need 30 to 60s, or it even just times out when travelling by train and being in a bad spot, connectivity wise. QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times (none) compared to TCP (even with TCP fast-open). So simple websites can profit too from QUIC, initial load time can get reduced a lot, browsing them is finally doable also on remote, spotty connections. Also, I happen to develop applications that are delivered as web app, they just tend to acquire a certain complexity even if one tries to stay simple, so loading that faster even if nothing is already cached is a welcome thing to me. Bloated page still will be slow, sure faster than with HTTP 1.1 but still slow, and I definitively would like to see that getting improved, but that's not really related to the issues that QUIC improves on, as simple websites win too when using it; it's just less noticeable there if you already have a somewhat OK connection. In summary: Why not invent a new protocol if you can significantly reduce overhead for everyone, especially if it can coexist with the simple and established one.

deepstack 5y ago
>QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times compared to TCP. hmmm abit skeptical on the less round-times. Are the all the round-times in TCP to ensure the integrity of the connection. With UPD it is my understanding that no confirmation of receiving packet is issued. So a server can send out a signal, but never can be sure if the client got it. I can see it can be great for multiplexing/broadcasting, but the switch the whole http protocol over like this, I can't imagine there won't be tons integrity and security issues.

ignoramous 5y ago

> It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where A good solution could have been AMP: https://amp.dev/ https://amp.dev/ > mostly to spy on me If only AMP was not beholden to an adcorp.

the8472 5y ago
Isn't the first thing AMP does pull in some javascript that was required to render the page? I recall there being some relatively long delay showing an empty page if you had some stuff blocked because it was waiting for a fallback. Or maybe that was some other google thing that did it. That's exactly the opposite of HTML first with small sprinkles of CSS and JS.
- ignoramous 5y ago
  Well, I meant, a web-standard like AMP aimed at clamping down webpage-obesity would be nice (instead of AMP).
  - the8472 5y ago
    I think most of that could be achieved by a bunch of CSP rules that disable various features. No frames, no 3rd-party js, various request types restricted to same-site and data: URIs. Don't grant sandbox: allow-same-origin and the site will be a unique origin on each visit, thus effectively disabling cookies. So it's already possible to achieve quite restricted subsets of what a website can do. The issue is agreeing on what subset is useful enough for many sites.

throwawaylinux 5y ago

Google wants to send you these blobs though, which is (one of the reasons) why they develop faster protocols.

dm33tri 5y ago

Sometimes when I have a very limited connection on mobile, nothing helps the web and no pages would load over https, even if it's just plain HTML. And if the connection drops, then it almost certainly won't recover and full page reload is necessary. Other protocols may work much better in such conditions, for example popular messengers can send and receive text, metadata and blurry image previews just fine. In some cases even voice calls are possible, but not a single website would load ever. I think HN crowd won't notice the changes. I hope that the protocol would improve experience for smartphone users without reliable 4G connection.

josefx 5y ago
> for example popular messengers can send and receive text, Your messenger isn't sending tens of megabytes for every message. > metadata and blurry image previews just fine. One might wonder why they don't just send the 4 MB JPEGs instead of those down scaled to hell previews if they work so well. > . In some cases even voice calls are possible Not only kilobytes of data, but kilobytes of data where transmission errors can be completely ignored. I have been in enough VoIP calls to notice how "well" that works in bad conditions. Everything points to putting websites on a diet being the correct solution. > And if the connection drops, then it almost certainly won't recover and full page reload is necessary. I would consider that a browser bug. No idea why the connection wont just timeout and retry by itself.
- Dylan16807 5y ago
  > Everything points to putting websites on a diet being the correct solution. It would help a lot but it's not a full solution. You also need to stop TCP from assuming that every lost packet is because of congestion, or it will take a slow connection and then underload it by a huge factor.
dangerbird2 5y ago
Yeah, one of the major uses of http/3 is that it can gracefully handle connection interruptions and changes, like when you switch from wifi to mobile, without having to wait for the tcp stream to timeout. That's a huge win for both humongous web apps and hackernews' idealized static webpage of text and hyperlinks.

msy 5y ago

The primary purpose of the web is now an app delivery platform & VM execution environment, not text delivery.

Cthulhu_ 5y ago
Anecdotal, most of my internet use is still finding and reading text based information. ...I mean it's to build a web application, but that's different.
wolf550e 5y ago
That is correct but irrelevant. When I reach a landing page that mainly has text content (whether it's a news article, a blog post, a company's "about us" or a product's features list/matrix or something else), the page should load fast. My browsers shouldn't need to make 100 network connections and download megabytes to display a thousand words of text and some images. It should be about 1 network connection and maybe dozens of kilobytes (for images). We are not complaining about the web version of productivity apps like email, spreadsheets, project management, etc. loading slowly. But a newspaper article should load faster than a social media feed, and often they don't.

javajosh 5y ago

Next you'll be telling people that rather than rent storage units to store all their extra stuff, and then build an app to track all of that stuff, to just not buy so much stuff in the first place. If you generalize this type of dangerous advice, then what happens to the American economy? The same applies to websites: if you don't add all that great good stuff into every page, then what happens to the programmer economy?[1] [1] Although satire is dead, killed by people actually espousing extreme views on the internet, I still indulge but am forced to explicitly tell the reader: this is ridiculous satire. Of course we should solve the root of the problem and not invent/adopt technology that enables our bad habits.

comeonseriously 5y ago

> Because said article is not transmitted with a dollop of html to structure it, and a sprinkle of CSS and JS to make it look nice. It's delivered to me buried in a mountain of extraneous garbage, pulled in from god-knows-where, mostly to spy on me or trying to sell me crap I don't need. But that is how 75% of the people reading this make their living...

posix_me_less 5y ago
Which is why putting that observation here on HN is so important. We can do something about it!

onion2k 5y ago

But maybe think about why it was perfectly possible to have functional, fast, and reliable webpages and applications in the 90s and early 00s, despite the fact that our networks and computers were little more than painted bricks and paper-mache by todays standards. I've been building web stuff since the 90s. Your memory of what it was like is flawed. Sites were slow to load. People complained about images because they took a while to load, and as soon as they completed the page jumped down and you lost your place. Moving from one page to another page on the same site required throwing all the HTML away and starting over, even in a web app like an email client (MSFT literally invented XMLHttpRequest to solve that). The HTML content itself was bloated with styles and font tags and table layouts. Often a tiny article would weigh in at 50KB just because it had been created in DreamWeaver or Hotmetal or something and the code was horrible. Thr web didn't feel fast back then. It was hellishly slow. I had perf budgets to get sites loaded in under 8s (and that was just measuring the time to a DOMContentLoaded event, not the same as today's Core Web Vitals idea of loaded). There's no doubt that the web is, in many places, bloated to shit. It's not worse though. It's significantly better. It's just that there's more work to be done.

usrbinbash 5y ago
>It's significantly better. Its not better if the only thing that keeps it afloat is the fact that broadband is ubiquitous by now (and that isn't even true for most of the world), and hardware got alot better. The main difference is that many people started using the web after the gamification and bloatation took over, so they are used to adbanners flying in, random videos which start playing, and phone batteries going flat just by looking at a news article. > It's just that there's more work to be done. But is that extra work necessary? Look at this threads page on HN. It loads 402 kb worth of content: the html, a tiny amount of JS that isn't even minified (and doesn't have to because its so slim), a small css file, 3 small gifs and the favicon. That's it. That's all the network-load required to display a usable, information-dense, not hard to look at and performant experience.

jameshart 5y ago

Can you be specific - Which sites are you actually complaining about here? This site, which we're on, delivers pages of comments (this very comment thread is around 50K of comment text) almost instantly. The Washington Post homepage loads in 600ms for me. 20K of text. Images load within about another 500ms. Their lead article right now is one of those visual feature ones with animations that trigger on scroll, so after the text first appears after 600ms, it takes a second or so longer for the layout to finish. But a routine text article page, I have a scrollable, readable text view within 500ms. CNN.com, a fraction slower, for a little less text, but a lot more pictures. When I click into one of their articles, within a few seconds, it starts streaming me 1080p video of their news coverage of the article. Imagine that on your 'fast functional 90s and early 00s' web. Or let's pick a technical resource. go.dev's landing page? No noticeable delay in loading for me, and that page has an embedded form for trying out Go code. Or reactjs.org, say? Loads up in 200ms for me, and then subsequent navigations on site among documentation pages take about 60ms. How about a government resource? irs.gov? The homepage maybe loads a little slower than I'd like, but FAQ pages are pretty responsive for me, with text appearing almost as soon as I've clicked the link. I'm not cherrypicking, these were the first few websites that came to mind to test to see if things are really as bad as you're portraying. And my impression is... you know? It's not that bad? I am not arguing that there aren't bad sites out there, but we need to stop pretending that the entire world has gone to hell in a handcart and the kids building websites today don't care about optimization. Substantive websites deliver substantive content efficiently and effectively, with a level of functionality and visual flair that the 90s/00s web could only have dreamed of.

password4321 5y ago
Is this with or without blocking ads?
- jameshart 5y ago
  I run an adblocker, like about 27% of web users, sure. Do you get substantively different experiences on those sites if you don't?

kobalsky 5y ago

regardless of website bloat, tcp is pure garbage when dealing with even minimal packet loss and it has always contributed to the crappy feeling that mobile connections have. if something doesn't start loading in 5 seconds and you are still giving it time without jumping up and down, tcp gave you stockholm syndrome. I'm not familiar with quic so I don't know how to feel about it, but we are in dire need of an alternative that doesn't require reimplementing the good parts of tcp over udp like every game and communication apps in the world do.

howdydoo 5y ago
Are you alluding to SCTP/DCCP? Or is there some other protocol I don't know about?
ReactiveJelly 5y ago
I think QUIC is gonna be it, at least for the next 10 years. It has unreliable, unordered datagrams, and a huge number of TCP-like streams, all wrapped in the same TLS'd connection. When I look at QUIC, I see old TCP protocols like IRC and telnet coming back. The difficulty of encryption pushed many applications into HTTPS so they could stay safe, even though HTTPS isn't a perfect fit for every app. With QUIC saying "You're as safe as possible and you have basically a UDP and TCP portal to the server, have fun", I think we'll see some custom protocols built / rebuilt on QUIC that were lying dormant since the age when encryption was optional. For instance, multiplayer games could probably just use QUIC as-is. Send the real-time data over the datagrams, and send the chat messages and important game state over the streams. Instead of some custom game communications library, and instead of connecting TCP and UDP to the same server, one QUIC library and one QUIC connection. Now it's within the reach of a solo indie developer who wants to focus on their game-specific netcode, and not on re-inventing networking ideas.
- jayd16 5y ago
  Does the HTTP/3 spec provide access to UDP-like (non-retransmitted) requests? It looks like this might need another extension?

hdjjhhvvhga 5y ago

> If we don't think about this Actually, in this case "we" means Google and a few other big companies whose aims are not the same as ours - they are the ones in charge. Sure, at times it happens that our interests are somewhat aligned (like page load times) but only as far as it serves them. For Google, a page without their code like ads/analytics is pretty much useless; for us, it's more useful because it doesn't track us and loads faster. So yes, while they continue doing some work in that respect, I expect it will actually go worse with time as they are focused on average consumer bandwidth in the USA. Once G5 is well entrenched and broadband/fiber gets even faster, we can expect even more bloat on websites and there is not much "we" (=users and developers) can actually do about it.

fiedzia 5y ago

The reason is that a) if it doesn't look good, most people will not take it seriously and b) you must have ads and tracking of user activity. What I really don't get is why bare html looks so awfully today and you have to add tons of js and css to get something acceptable.

usrbinbash 5y ago
> and you have to add tons of js and css to get something acceptable No we don't. As I have written before in this topic, HN is the perfect example. It pulls in a small css and js file, both of which are so slim, they don't even require minifying. The resulting page is small, looks good, is performant and most importantly does its jobs. We don't need megabytes worth of cruft to display a good looking page.
- fiedzia 5y ago
  > HN is the perfect example. It pulls in a small css and js file, both of which are so slim, they don't even require minifying. The resulting page is small, looks good It looks good for technical people. It does not look good for others.
  - usrbinbash 5y ago
    Pretty sure my mum would love for her recipe websites to fit the entire recipe on screen at once, instead of having to scroll over a gigantic font, interlaced with 4+ irrelevant pictures of smiling people holding fruits and 2 ad banners, canceling the ubiquitous "we use cokkies balabla.." popup and maybe some full-page ad-overlay. I am also sure she would love these selfsame pages to load instantly when shes accessing them via her old cell phone at my uncles house where reception is bad and the device has to revert to 3G. No, "other" people don't want bloat, tons of adds and "clever designs" (aka. a huge useless picture-banner that contains zero information) either.
    - fiedzia 5y ago
      Great examples. Downloaded size for top 3 sites for recipes: https://www.bbcgoodfood.com/ https://www.bbcgoodfood.com/ - 12MB https://www.jamieoliver.com/ https://www.jamieoliver.com/ - 4.3MB https://www.deliciousmagazine.co.uk/ https://www.deliciousmagazine.co.uk/ - 8.4MB It seems their users didn't wanted them to be so barebone. I am not saying people want bloat, but they won't accept HN-style simplicity. What I'd like to have is good looking sites with no CSS at all, just make them acceptable by default, and a lot of this bloat will simply go away.

hdjjhhvvhga 5y ago

Oh this is hilarious: > The tech lead for Google's AMP project was nice enough to engage us on Twitter. He acknowledged the bloat, but explained that Google was "resource constrained" and had had to outsource this project > This admission moved me deeply, because I had no idea Google was in a tight spot. So I spent a couple of hours of my own time making a static version of the AMP website. . . > By cutting out cruft, I was able to get the page weight down to half a megabyte in one afternoon of work. This is eight times smaller than the original page. > I offered my changes to Google free of charge, but they are evidently too resource constrained to even find the time to copy it over.

deleted 5y ago

[deleted]

ReactiveJelly 5y ago

> It's sad that we need this. No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually. Look back at the small site hosted in Bangalore - That's an Indian version of me. A hacker whose projects can't run on self-hosted Wordpress, who only bought a VPS because their home ISP is not reliable. With HTTP/1, most of America can't load their site, it times out. With HTTP/2, it takes 2,500 ms. With HTTP/3, it takes 1,000. A _petty_ software upgrade allows this imagined Indian blogger to gain an audience on _another continent_ without buying more servers, without using a CDN, and without taking advertising deals to afford more stuff. You know 3 things I hate about the web? Advertisements, CDNs, and having to buy servers. I promise this is purely geographical, not political - How often do you connect to servers outside the USA and Europe? I mean trading packets with a computer. YouTube uploads don't count because they have a CDN. For me, the answer is "almost never". The Internet is supposed to be global, but computers are made of matter and occupy space, so connections to nearer servers are still better, and they always will be. But QUIC makes the far-away connections a little less bad. That is a good thing.

combyn8tor 5y ago
A CDN solves those issues and is significantly faster than HTTP3 in your use case... why the hate for them? The centralised aspect?
- anonymoushn 5y ago
  TCP head-of-line blocking is a huge problem. Almost nothing should use TCP. I am happy if people use CDNs but even happier if people use HTTP/3.
Dylan16807 5y ago
> With HTTP/1, most of America can't load their site, it times out. That shouldn't happen. Do you have a real site in mind there? > No, it's not, multi-dimensional optimization and improvement-in-depth is good, actually. That can be true at the same time as "it's sad that we need this"

Chris2048 5y ago

Monetisation. The old internet didn't have enough rent-seekers gatekeeping the content. Even Wikipedia begs for money it doesn't need.