Hacker News new | past | comments | ask | show | jobs | submit
botanical | on: QUIC is not quick enough over fast internet
> we identify the root cause to be high receiver-side processing overhead

I find this to be the issue when it comes to Google, and I bet it was known before hand; pushing processing to the user. For example, the AV1 video codec was deployed when no consumer had HW decoding capabilities. It saved them on space at the expense of increased CPU usage for the end-user.

I don't know what the motive was there; it would still show that they are carbon-neutral while billions are busy processing the data.

danpalmer | parent | next
> the AV1 video codec was deployed when no consumer had HW decoding capabilities

This was a bug. An improved software decoder was deployed for Android and for buggy reasons the YouTube app used it instead of a hardware accelerated implementation. It was fixed.

Having worked on a similar space (compression formats for app downloads) I can assure you that all factors are accounted for with decisions like this, we were profiling device thermals for different compression formats. Setting aside bugs, the teams behind things like this are taking wide-reaching views of the ecosystem when making these decisions, and at scale, client concerns almost always outweigh server concerns.

watermelon0 | root | parent | next
YouTube had the same issue with VP9 on laptops, where you had to use an extension to force H264, to avoid quickly draining the battery.
toastal | root | parent
If only they would give us JXL on Android
anfilt | parent | next
Well I will say if your running servers hit billions of times per day. Offloading processing to the client when safe to do so starts make sense financially. Google does not have to pay for your CPU or storage usage ect...

Also I will say if said overhead is not too much it's not that bad of a thing.

kccqzy | parent
This is indeed an issue but it's widespread and everyone does it, including Google. Things like servers no longer generating actual dynamic HTML, replaced with servers simply serving pure data like JSON and expecting the client to render it into the DOM. It's not just Google that doesn't care, but the majority of web developers also don't care.
SquareWheel | root | parent
There's clearly advantages to writing a web app as an SPA, otherwise web devs wouldn't do it. The idea that web devs "don't care" (about what exactly?) really doesn't make any sense.

Moving interactions to JSON in many cases is just a better experience. If you click a Like button on Facebook, which is the better outcome: To see a little animation where the button updates, or for the page to reload with a flash of white, throw away the comment you were part-way through writing, and then scroll you back to the top of the page?

There's a reason XMLHttpRequest took the world by storm. More than that, jQuery is still used on more than 80% of websites due in large part to its legacy of making this process easier and cross-browser.

consteval | root | parent | next
> To see a little animation where the button updates, or for the page to reload with a flash of white, throw away the comment you were part-way through writing, and then scroll you back to the top of the page

I don't understand how web devs understand the concept of loading and manipulating JSON to dynamically modify the page's HTML, but they don't understand the concept of loading and manipulating HTML to dynamically modify the page's HTML.

It's the same thing, except now you don't have to do a conversion from JSON->HTML.

There's no rule anywhere saying receiving HTML on the client should do a full page reload and throw up the current running javascript.

> XMLHttpRequest

This could've easily been HTMLHttpRequest and it would've been the same API, but probably better. Unfortunately, during that time period Microsoft was obsessed with XML. Like... obsessed obsessed.

tock | root | parent | next
I don't think Facebook is the best example given the sheer number of loading skeletons I see on their page.
kccqzy | root | parent
Rendering JSON into HTML has nothing to do with XMLHttpRequest.

Funny that you mention jQuery. When jQuery was hugely popular, people used it to make XMLHttpRequests that returned HTML which you then set as the innerHTML of some element. Of course being jQuery, people used the shorthand of `$("selector").html(...)` instead.

In the heyday of jQuery the JSON.parse API didn't exist.