News for hackers. Stuff that matters.
Re:Don't Animate Height by legitster on Tuesday July 22, 2025 @05:26PM (#44653176)
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.

Re:Don't Animate Height by sema4hacker on Tuesday July 22, 2025 @08:44PM (#44654589)
I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
Re:Don't Animate Height by adastra22 on Wednesday July 23, 2025 @05:31AM (#44657279)
All modular, I hope.
Re:Don't Animate Height by nonethewiser on Wednesday July 23, 2025 @10:08AM (#44659414)
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.

Re:Don't Animate Height by dotancohen on Tuesday July 22, 2025 @11:29PM (#44655475)
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.
Re:Don't Animate Height by bartread on Tuesday July 22, 2025 @11:42PM (#44655539)
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).

Re:Don't Animate Height by jaapz on Wednesday July 23, 2025 @06:12AM (#44657503)
Couldn't they just have used an animated gif or png, the amount of CPU used probably wouldn't even be measurable
Re:Don't Animate Height by cpmsmith on Wednesday July 23, 2025 @10:32AM (#44659660)
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.
Re:Don't Animate Height by naikrovek on Wednesday July 23, 2025 @08:48AM (#44658627)
> 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.

Re:Don't Animate Height by atiedebee on Thursday July 24, 2025 @07:08AM (#44669313)
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.