3 ms·

> 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 ha

> 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.

anfilt 2y ago
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 2y ago
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 2y ago
  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.
  - tock 2y ago
    I don't think Facebook is the best example given the sheer number of loading skeletons I see on their page.
  - consteval 2y ago
    > 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.
  - kccqzy 2y ago
    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.
danpalmer 2y ago
> 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 2y ago
  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 2y ago
  If only they would give us JXL on Android

anfilt 2y ago

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 2y ago

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 2y ago
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.
- tock 2y ago
  I don't think Facebook is the best example given the sheer number of loading skeletons I see on their page.
- consteval 2y ago
  > 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.
- kccqzy 2y ago
  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.

danpalmer 2y ago

> 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 2y ago
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 2y ago
If only they would give us JXL on Android