Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't animate height

granola.ai

Post reply on HN
Print view View original

241–250 of 276 posts

Re: Don't animate height

#241

Post by gf000 »

ajsnigrutin wrote: post #226
crazygringo wrote: post #127

Earlier quoted context omitted.

For a news article, absolutely. But I think it needs to be able to handle JavaScript-heavy webapps too. My suggestion wasn't really about promoting maximum best practices, but just avoiding total runaway excess.

MS word on a 133mhz pentium and 16mb of ram needed less than 5s to start. Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.

There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.

Re: Don't animate height

#242

Post by gf000 »

adastra22 wrote: post #224
valenterry wrote: post #187

Earlier quoted context omitted.

That's very very sad. Animations can make UX much better when used correctly.

…how? How do they improve the user experience, at all?

Absolutely, without question. Do you think that humans, who evolved in a physical word where basically everything happens in an incremental way don't extract valuable information from in-flight state?

Also, as an example just try to use a window manager that just switches instantly to a new desktop, vs a very short animation. I find the former easily disorienting, and it is even more so when you have a more direct gesture controlling the action (e.g. touch or mousepad). Of course there is too much of everything, and too much animation sucks, no question. So is too much fat, but that doesn't make normal amounts any bad.

Re: Don't animate height

#243

Post by HWR_14 »

pohuing wrote: post #162
zuhsetaqi wrote: post #88

Earlier quoted context omitted.

Keep in mind that the percentage in Activity Monitor is 100 % per core, so a 10 core CPU can go up to 1000 % usage. So 60 % means 60 % of a single core not of the whole CPU.

And it's sensitive to dynamic scaling as well, isn't it? So it's possibly not 60% of a core at max clock, but maybe of a core clocked to 800mhz or something. I fell for that shallow analysis myself once when I noticed just how apparently bad the gpu usage was for a big of animation in a web page, until I noticed my 30% load gpu still drew as much wattage as it did on idle.

So it's 60% of the battery optimal usage? So 10 cores can get to 2000%?

Re: Don't animate height

#245

Post by deno »

gf000 wrote: post #241
ajsnigrutin wrote: post #226

Earlier quoted context omitted.

MS word on a 133mhz pentium and 16mb of ram needed less than 5s to start. Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.

There are full on CAD apps nowadays on the web. Also, this "looking down" on such a huge group of people is pretty questionable behavior.

This isn’t unsolvable. A CAD app or similar could ask for permission to use extra resources. There’s already one for storage, extending this to CPU and MEMory is not far fetched.

Re: Don't animate height

#246

Post by troupo »

kadoban wrote: post #221
troupo wrote: post #213

Earlier quoted context omitted.

Translation: just make a completely different functionality and effect than what was originally intended because the DOM can only handle static content, barely.

The suggested change wouldn't affect functionality or the effect. It just tells the browser that there's a thing around the changing part with a fixed size that can't possibly change layout of anything around it, to the user it's invisible.

It will literally change the intended functionality by, placing it in a container of fixed height and overflow hidden

Re: Don't animate height

#247

Post by troupo »

RumourRider wrote: post #215
troupo wrote: post #214

Earlier quoted context omitted.

> If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"

Yes it will. Most of the CSS styling is literally wrappers around draw calls.

Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"?

Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc."

Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but will only consume 6% if you go out of your way to make it 'performant'"?

Re: Don't animate height

#248

Post by astura »

>On my M2 MacBook, the renderer process is now using 6% CPU (down from 15%), and the GPU process is now using 6% CPU and less than 1% GPU (down from 25% and 20%).

I honestly can't imagine typing this out and patting myself on the back rather than thinking "wtf am I doing? It's 2025, I have a high end laptop, and this is a note taking app. The total resource utilization should be close to zero."

Modern devs are fucking hogs.

Re: Don't animate height

#249

Post by naikrovek »

here's an idea - don't animate anything on a webpage.

Just. Don't.

NO ONE needs animation to convey information, unless that information is an animation, such as in an educational context, where interactive things demonstrate what is being taught.

I don't need to see your widget spin in 3d while I scroll down the page. I really don't. I don't even want to see that.

Web pages are slow because people make them slow. Stop making them slow.

Re: Don't animate height

#250

Post by naikrovek »

bartread wrote: post #184
legitster wrote: post #115

Earlier quoted context omitted.

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

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

Post reply on HN