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

31–40 of 276 posts

Re: Don't animate height

#31

Post by xp84 »

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the or whatever. Do it at 2x and scale it for retina sharpness.

But modern "web designers" feel the need to spend how long carefully crafting that CSS animation which adds dozens of lines of code to the codebase and burns a ton of CPU...why? Just because you can, I assume? The same reason the same people use embedded documents inside the HTML for simple icons like "edit pencil" or "close", wasting bandwidth instead of at least putting them into asset files that can be cached.

Frontend web "advancements" of the last 10-15 years, at least the way they are used, are mostly cancer in my opinion. I will allow for the usefulness of display: flex, and that's about it.

Re: Don't animate height

#32

Post by xp84 »

dylan604 wrote: post #17
jtangelder wrote: post #3

Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.

If the bars are not related to actual data and are purely just pre-canned animation, the gif would just come with additional file size for a one time cached type of download. If the bars do need to be animated to real-time data coming in, then the gif would not be the right fit for that need.

I've almost never seen these tiny icons to have any actual useful information being conveyed (meaning they are tracking amplitude or pitch). They're usually purely decorative, or boolean in function, meaning you can see they're flat if you are completely silent or they're bouncing around if not silent.

You can have 2 GIFs for "silent" and "sound happening" if one cares to truly indicate if it's picking up sound / playing sound, and switch between them. Will be 1000x simpler and 99% fewer lines of code to maintain forever.

Re: Don't animate height

#33

Post by verall »

Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about.

I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case.

Because honestly I think this is horrifying. I would rather it switch from grey to red "recording" dot than use even the 6% the author decided was "fixed". In 99% of cases I do not care at all about the "artistic vision" of the UI designer and in the other 1% of cases (say an in-browser game or some useful data-viz) I could choose to allow the tab to go crazy with my resources.

Re: Don't animate height

#34

Post by nawgz »

xp84 wrote: post #31

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the or whatev…

Yes you're right, most users LOVE barebones and classic websites, that's why HN is so popular and Reddit hardly has any users.

For that matter, do we really need colors? Just ship it with browser default styles.

Re: Don't animate height

#35

Post by jakubmazanec »

xp84 wrote: post #31

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the or whatev…

GIFs don't scale well (including 2x version is not enough); with CSS (and SVG) you get crisp graphics at any scale. And of course you can use asset SVG files that are cached [1].

[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...

Re: Don't animate height

#36

Post by xp84 »

nightpool wrote: post #14
jtangelder wrote: post #3

Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.

GIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.

I disagree. The height of a DOM element is much more expensive to recompute as this article shows than a single element which gets frames swapped out with static images. The latter can be guaranteed to never impact any other part of the document. The end result of either is that the pixels in the animated area need to be recomputed, and end result which will be the same for both, but a GIF will have no further impact on anything else whereas resizing DOM elements has side effects that have to be constantly updated and checked for which scale with the number of sprites you're animating (unlike the GIF bitmap which is gonna be 'flat rate').

Likewise, for a tiny animation, having the frames of the GIF in memory and blitting them onto the screen in sequence sounds like orders of magnitude less CPU/GPU than performing all the ridiculous math-based transforms over and over again.

The Tumblr example is not instructive here because those were frequently many many frames, very colorful (often photos), and/or large in dimensions, taking up a ton of memory which was probably the main problem causing our browsers to choke. This would be none of those things.

Re: Don't animate height

#37

Post by moritzwarhier »

Eric_WVGG wrote: post #21

My head is sort of reeling from this. If height animations are that expensive today, imagine how expensive (and still commonplace) they were twenty years ago. I fortunately quit animating height quite a long time ago in favor of similar transform techniques, but… wow, still crazy to learn the magnitude of this common operation.

It's really simple. Don't animate layout, especially if your DOM is huge.

If your element floats absolutely positioned outside the layout flow, animating height would not be a problem.

And if the browser facilities for animating height/max-height, especially to/from auto, get better, it surely will become more common.

Right now, I wouldn't call it common. It's a common requirement, but only until you start to consider layout.

Fwiw, animating margin and padding is possible and has the capability to cause the same amount of jank as animating height.

Re: Don't animate height

#38

Post by norskeld »

jtangelder wrote: post #3

Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.

Personally, I'd be annoyed by both the resource-consuming animations and the blurry GIFs/canvas. Infisical does use the latter (canvas) for icons in their UI, and I somewhat hate it. I'd rather look at crisp, but static icons.

Re: Don't animate height

#39

Post by xp84 »

dylan604 wrote: post #28
bitpush wrote: post #25

Earlier quoted context omitted.

Might be worth getting off of that high horse. You are not being very smart by saying 'akctually electron bad'. You know what else was a waste of electrons? Your comment, and my reply.

Your reply was not necessary though. Every electron app uses more of my computer's resources than when I use the same service through the web browser.

Yes! And the electron app 90% of the time can't work offline anyway (or often would be useless even if it tried). So it's just an extra 2 gigs of space wasted on my SSD for another copy of Chromium, instead of having the website be an "App" installed in Chrome or Edge and granted notification (etc) permission.

In my opinion, most things shouldn't bother to make an "app," and certainly shouldn't try to push their apps on me, unless they want to make an actual native app for their target platforms.

Re: Don't animate height

#40

Post by panic »

xp84 wrote: post #31

Here's the part that makes me confused/angry: this is a flat style icon with maybe 4 or 8 colors displayed on a static flat green background. I could have built this 25 years ago with a single GIF with about 6 frames, that was a couple of kilobytes and would be performant on the (relative) potato computers we had then. With CSS you can easily make that GIF a background image and position it correctly in the or whatev…

Won’t the GIF also burn a ton of CPU? I’m not convinced it would actually be more performant than sliding textures around.
Post reply on HN