Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As an old-school webguy, fixes like this article make me sad.

The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.



Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor.

How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case.

The acceptable range would be something like 0 - 1% when no interactions are taking place.

I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there.

Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).


> Front-end web devs need to have more respect for power consumption and battery life

they need to understand and believe that their wishes are not everyone's wishes, and that they alone are the cause of their own problems. Everyone else works hard to give them the creative freedom they demand, but for multiple decades now they have demonstrated over and over how they love shooting themselves in the foot at every opportunity.

> consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable?

It's not acceptable, unless you are a front-end web developer. If you are a front-end web developer, you don't consider this a problem in any way because the page looks as it is intended to look.


Couldn't they just have used an animated gif or png, the amount of CPU used probably wouldn't even be measurable


You might be surprised at the CPU usage of rendering a GIF. I'm not sure why, but I've previously noticed Slack takes noticeably more CPU when there's an animated emoji on screen.


A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.


I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.


Looks like its using YUI (a yahoo UI library) that was deprecated in 2011 in favor of YUI 3 (which is now deprecated as well). https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html

Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.


All modular, I hope.


huh, that was probably the least infuriating filter I have encountered in a while.

It's frustrating how just changing a filtering option will reload the entire web page on most websites.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: