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

151–160 of 276 posts

Re: Don't animate height

#151

Post by RumourRider »

alexchantavy wrote: post #108
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 .

Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?

You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually.

If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.

There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is out of date now due to improvements in Browser engines, the fundamental ideas are still the same.

https://www.youtube.com/watch?v=mHtdZgou0qU

If you skip to the 35 minute mark he speaks about reflow specifically. Generally I still use many of these techniques when writing vanilla JS (which is unfortunately rare these days). There are other talks where he talks about many other performance specific topics.

Obviously none of this is as good as real world experience of dealing with a thorny issue.

Re: Don't animate height

#153

Post by Levitating »

xp84 wrote: post #39
dylan604 wrote: post #28

Earlier quoted context omitted.

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…

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

It's as people have just forgotten that software used to integrate with the rest of the computer. I know people who install things like Netflix as apps just to have an icon on the taskbar.

Re: Don't animate height

#154

Post by makeitdouble »

endemic wrote: post #69

ironic that the benefit of using web tech (platform abstractions) can be totally negated by such a small footgun, which then requires insane knowledge of the browser rendering pipeline to solve

> insane knowledge of the browser rendering pipeline to solve

Saying it having not much of that knowledge myself: it's reasonable to sometimes need platform knowledge to make intricate things (here a realtime animation) behave efficiently.

That's the same for game engines, native rendering, flash animations etc. There will always be edge cases, building enough stuff you'll hit them, and if you care about doing it right it will require knowledge to overcome the issues.

Re: Don't animate height

#155

Post by Levitating »

deathanatos wrote: post #139
Saris wrote: post #116

Why are the bars on a little button animated in the first place? I don't get it.

This looks like a very typical audio recording UI element. The bars are animated to the volume of the recorded audio. Helps the user see that the application is picking up their mic. It's a digital analog of a VU meter on a mixing console, though the UI has morphed over time. (Like that the lines vertically centered, vs. being on aligned bottom like you might see on a real-world meter.)

Except that it's not an actual meter, it's just a fake animation.

Re: Don't animate height

#156

Post by Levitating »

jbeninger wrote: post #97
Sharlin wrote: post #75

Earlier quoted context omitted.

One problem is that this is supposedly considered insane esoteric knowledge, when the concept of reflows, and why and when they're triggered, ought to be fairly basic knowledge to every reasonably experienced frontend coder. Up there with "O(n^2) may bite you in the ass". But we've decided that optimizing SEO or conversion rates or whatever is much more important than optimizing rendering.

I think there's a bit of an "everybody knows that" [1] phenomenon when it comes to knowledge like this. Devs come from different backgrounds and work on different types of projects. There are 10000 things you expected to know to be an expert, and all of us are continually learning. [1] https://xkcd.com/1053/

Except that this is the developer of an apparently popular and well-invested product.

If you expect to make a note taking app, which only has a piece of text, a stop button and a floating animation, I hope that you figure out why your performance is being tanked by your single animation.

Re: Don't animate height

#157

Post by Levitating »

trafnar wrote: post #7
zahlman wrote: post #4

... Why does a "note-taking app" have an "audio volume visualizer"??? Edit: kinda funny how I asked what I thought was a reasonable question and expressed entirely understandable confusion; got an upvote almost right away; then got multiple downvotes after people answered the question — as if it somehow suddenly became obvious why I should have expected such a feature a priori.

Their app listens to your calls and transcribes things. I think this visualizer helps indicate when it is actively listening.

So why does it need to be animated, a color indication could've worked just as well. Or the stop button right next to it...

Re: Don't animate height

#159

Post by zdragnar »

makapuf wrote: post #124
zdragnar wrote: post #61

Earlier quoted context omitted.

They're generally static documents that could be served independently, and thus cached, like an image. Many times, though, they're served up inline in the JavaScript code that templates the html, and thus is cached less aggressively, especially if the FE is deployed frequently.

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

Post reply on HN