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

271–276 of 276 posts

Re: Don't animate height

#271

Post by deepsun »

kadoban wrote: post #220
fiddlerwoaroof wrote: post #185

Earlier quoted context omitted.

I don't understand how you'd fix this, in general, for the browser: the browser can't just assume certain animations will never affect layout.

It could _probably_ figure out a lot of cases via some kind of static or runtime analysis. Like the example from the linked article, there's one animation involved essentially and if the browser does the hard work for the entire length of one animation cycle and no layout ever changes, just assume it never will? It would have to have a bunch of edge cases to handle correctly I'm sure though.

Browsers layout engines are pretty smart, and also optimized for speed at the same time, which makes them very complex. I can do one or the other in my code, but both is too hard. Now add there security.

But Google having more people working on Chrome than on Android I would say all the low-hanging optimizations have already been optimized, and all that's left is pretty complex even for teams of thousands.

Re: Don't animate height

#272

Post by adastra22 »

gf000 wrote: post #242
adastra22 wrote: post #224

Earlier quoted context omitted.

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

People are different, I guess. I remove those animations whenever I can. A desktop manager that switches virtual displays in a single frame is exactly what I want.

Re: Don't animate height

#273

Post by atiedebee »

legitster wrote: post #115
deepsun wrote: post #50

Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .

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.

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.

Re: Don't animate height

#274

Post by ptspts »

bobthepanda wrote: post #63
ajkjk wrote: post #58

Earlier quoted context omitted.

This contempt is misplaced. It is obviously better in one sense to generate an animation on the fly using a short program instead of encoded its literal pixels in a much larger amount of data even after compression. The ecosystem has largely moved towards that abstraction because it scales better for virtually every purpose, particularly for rendering in different formats. Now web developers are brought up inside the…

The problem is that everyone (browsers + developers) need to agree on a replacement, which is notoriously hard to do. Chrome got laughed out of the room with Dart/Flutter.

Supporting arbitrary image formats and compression methods in the browser is easy: just ship the decoder as a WebAssembly function.

(This is not any better solution than GIF or aPNG though for the problem in the article.)

Re: Don't animate height

#275

Post by xp84 »

deathanatos wrote: post #207
xp84 wrote: post #197

Earlier quoted context omitted.

I can't use the app in question, but I haven't seen any proof it doesn't just "dance when receiving audio". If it tracks amplitude and pitch, I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, quiet, not quiet).

True, the article didn't say that it for sure isn't being used as a glorified GIF, but … why not just give the benefit of the doubt that it UI element is doing the thing the UI element ought to do? Then, "Here's how that turned into a performance problem" followed by the rest of the article. > I'd still say it's overengineered, since in practice no one can discern anything useful except 2 or maybe 3 states (silent, q…

We agree that 2-3 states is all we need to discern -- I was just saying that if it's actually wasting even more CPU by truly analysing both the amplitude and frequencies in the audio, I'd chastise whoever decided to do that for wasting time when "sound" "quiet sound" and "loud sound" serves 100% of the use cases for this widget.

And the above is a separate question unrelated to implementation. A true VU meter in CSS animation is the most overengineered, a glorified GIF built as a CSS animation is somewhat overengineered, and a couple of simple GIFs is the simplest.

Re: Don't animate height

#276

Post by makapuf »

zdragnar wrote: post #159
makapuf wrote: post #124

Earlier quoted context omitted.

Wasting hundreds , well maybe a thousand of bytes in the process ! (I understand it's better to cache and things can go out of hand fast. But we're talking about small animations here.

I don't disagree at all. There's way bigger fish to fry when it comes to maximizing network efficiency in websites. I'm just pointing out the rationale of OP since someone asked, and I've worked with people who've made this and similar arguments before. It's been awhile, though- the ones I'm thinking of would treat code golf as a best practice for CSS (only slightly exaggerating).

Of course, we both agree.
Post reply on HN