[HN Gopher] Don't animate height
___________________________________________________________________
Don't animate height
Author : birdculture
Score : 227 points
Date : 2025-07-19 20:44 UTC (3 days ago)
(HTM) web link (www.granola.ai)
(TXT) w3m dump (www.granola.ai)
| andrewstuart wrote:
| I seem to recall reading that Chrome has height transition
| optimizations coming.
| jtangelder wrote:
| Wondering what the performance of a simple animated gif would be,
| instead of the composite layer transformations.
| nightpool wrote:
| 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.
| xp84 wrote:
| 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.
| evan_ wrote:
| Or if you need to actually control it, an SVG or <canvas> based
| animation
| dylan604 wrote:
| 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.
| threetonesun wrote:
| Can't imagine anyone is deriving much information value from
| a visualizer with 3 bars. Apple Music has a similar animation
| and it will start bouncing when you click play, while the
| music is clearly downloading and there's no sound.
| dylan604 wrote:
| Just because it isn't useful to the user doesn't mean some
| dev hasn't spent the cycles doing it. I know I've
| personally had to write code that was an absolute waste,
| but some PM wanted and it was coded. Usually so it can be a
| bullet point in a demo that impresses low skilled PMs or
| sales drone, but techy user types just roll their eyes when
| it's pointed out to them.
| hbn wrote:
| I think a mic visualizer is very useful to the user. You
| can tell if you're quiet, clipping, or your mic straight
| up isn't working at all.
| dylan604 wrote:
| You've moved the goal posts. Nobody said an input levels
| indicator isn't useful. We're talking about this specific
| graphic not being a useful graphic for visualizing live
| data. You've wandered away from the pack here
| will-bradshaw wrote:
| This was true pre iOS 18. The bars respond to the music now
| (at least on iOS)!
| threetonesun wrote:
| Ah, look at that, so they do!
| xp84 wrote:
| 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.
| DamonHD wrote:
| And won't annoy people who get over-stimulated.
|
| I don't normally have that issue, but one site had (has?) a
| bright green thing that jumped periodically that was so
| vastly distracting that I could not read the text on the
| page without covering the 'thing' somehow, eg with my hand!
| Absolutely pointless. I had to give up using the site
| entirely, even though it was otherwise useful.
| mrob wrote:
| If you use uBlock Origin on Firefox, it's very easy to
| remove that kind of annoyance using the "element zapper"
| mode. See:
|
| https://github.com/gorhill/uBlock/wiki/Element-zapper
| norskeld wrote:
| 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.
| jasonjmcghee wrote:
| Canvas should never be blurry. If it is, something is doing a
| bilinear upscale. I'd guess someone forgot to take the scale
| factor of your display into account.
|
| Or there are images being used in the canvas, which would
| defeat the purpose for the use case you described.
| zahlman wrote:
| ... 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.
| samgutentag wrote:
| The product makes notes from the transciptions, so this
| animation isnt wildly off base to have
| satvikpendem wrote:
| Transcribed voice notes
| trafnar wrote:
| Their app listens to your calls and transcribes things. I think
| this visualizer helps indicate when it is actively listening.
| h1fra wrote:
| dumb question: would putting the parent div in absolute
| positioning solve the compositing?
| Eric_WVGG wrote:
| It already was. The whole point of this is that any height
| change is part of an expensive phase of the rendering pipeline.
| HWR_14 wrote:
| What amazes me is that so much a M2 Mac's resources would be used
| to render a website even if it rendered everything from scratch.
| There is almost no graphic content compared to a video game
| produced decades ago, and they would easily render a frame in 1/2
| the time on decades old hardware
| hombre_fatal wrote:
| Well, raw graphical content is the easy part.
|
| A live layout tree that has to be repainted and composited yet
| intersect with arbitrary layers like an accessibility tree and
| what would naively be N:N style calculations is completely
| different architecture.
|
| Consider examples where people toy with the concept of
| replacing the DOM with a canvas but basic things like text
| selection don't even work anymore.
| zuhsetaqi wrote:
| 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.
| JakeSc wrote:
| Great writeup. With LLMs doing an increasing amount of the coding
| now, it would be great for the browser or development environment
| to have built-in validations that enforce good performance. The
| coding agent (or human) would get direct, immediate feedback at
| development time that there's a performance threshold violation,
| at development time.
| paulirish wrote:
| We're working on this within Chrome DevTools, similar to an MCP
| server with the signals you're describing.
| alterom wrote:
| So, after all the optimization, they're using 6% of the CPU to
| display what amounts to a tiny animated GIF that 1990s PCs would
| have no problem with.
|
| _But it 's vector graphics!_, you might say. Yeah, like Flash,
| which ran fine on Pentium II, with plenty CPU cycles to spare.
|
| Pardon me, and I don't say it lightly, but... _WTF?!_
| smallpipe wrote:
| Yeah author congratulating themselves at the end because their
| note app is only using hundreds of millions of cycles every
| seconds, to do essentially nothing...
| another_one_112 wrote:
| I do miss flash, but we shall not forget that the performance
| boost came from low level access to the system (which made it a
| security risk).
| Dylan16807 wrote:
| I strongly doubt its ability to render a fast rounded
| rectangle needed that.
| bob1029 wrote:
| I would also suggest looking into the following in this case:
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/contain
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/will-change
|
| There are hints you can provide to the browser that may have an
| impact in scenarios where you are animating layout properties.
| bijection wrote:
| I was just starting a comment on this but you beat me to it! I
| believe contain: strict;
|
| on the parent element would have been sufficient here.
| webstrand wrote:
| I tested `contain: strict` on their color changing SVG and
| didn't see any difference. Profiler says it's still doing
| layout.
| spankalee wrote:
| CSS contain has made so many performance "truths" obsolete, but
| so few developers realize it. I've seen massive efforts to do
| things like port text editors to WebGL where rasterizing text
| is a huge pain where putting `contain: content` on the
| individual elements in the DOM version would have delivered
| most of the perf improvements.
|
| Browser rendering engines are now sophisticated GPU-accelerated
| compositors. Absolute positioning with contain: strict removes
| basically all CSS layout from the perf equation, and you don't
| have to write your own compositor or line-layout! `* {contain:
| content}` and flex/grid gets you the good parts of HTML and
| very good performance.
| dylan604 wrote:
| "What is Granola spending those cycles on? It's an Electron app"
|
| Yup. Matches my experience with pretty much every Electron app.
| Great that the dev tracked it down, but every Electron app is a
| waste of...electrons
| bitpush wrote:
| 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.
| dylan604 wrote:
| 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.
| bitpush wrote:
| Do you have that documented somewhere, or is it just your
| observation?
| dylan604 wrote:
| I no longer have the app, but Slack uses <500MB of memory
| and .2% CPU in a tab in my browser. Back when I had the
| Slack electron app it was way more than that in use of
| system resources. I don't know what else to tell you. I
| don't know what other documentation would be interesting
| other than my observations made on my own equipment
| xp84 wrote:
| 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.
| ASalazarMX wrote:
| You could have a very, very long exchange of wasted electrons
| here to be in the scale of an Electron app starting up.
| jasonjmcghee wrote:
| Seems like a great use case for a tiny canvas instead.
| Eric_WVGG wrote:
| 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.
| moritzwarhier wrote:
| 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.
| hbn wrote:
| The heart of the issue isn't that animating height is
| expensive, it's the downstream effect of that animation
| repeatedly changing the page's layout and forcing redraws.
| cvoss wrote:
| But it wasn't expensive twenty years ago. Twenty years ago
| people actually knew how to efficiently use their limited
| computational resources.
| Liftyee wrote:
| This helped explain why my PC uses so many resources "with just a
| few webpages open". I didn't realise that graphical updates that
| seem so simple could be so resource-intensive.
| dvt wrote:
| Is it just me, or have a lot of modern startups lost the plot?
| Imagine doing all this work for an element of your app which has
| nothing to do with its feature set. No one cares (certainly no
| customer) about an audio visualizer bar animation.
|
| The post is also riddled with all kinds of misunderstandings, as
| well. For example, the authoritative language used to describe
| the differences between layout/painting/compositing is just
| simply untrue generally speaking (though it might be w.r.t.
| Electron/Chromium). The W3C does not care how you implement your
| rendering engine, and even bringing up the spec betrays a
| misunderstanding of how these things work.
|
| In typical fashion, we see yet another grandiose blog post about
| fixing a "perf issue" for your hipster new startup that is
| essentially notepad.exe. Who funds this shit?
| woodpanel wrote:
| This was my thinking, too.
|
| Why distract users with giving an auxiliary feature so much
| prominence? Why wasn't a GIF enough? Or just an SVG that
| consists of 3 frames?
|
| Spending this much time on fixing this bug was worthwhile (at
| least it created a HN front page article) but the solution was
| not. 6% CPU usage is horrible.
| xp84 wrote:
| 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 <button> 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 <svg> 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.
| nawgz wrote:
| 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.
| seemaze wrote:
| Exactly this! I wish the entire web was easier to read on my
| e-ink device.
| LastMuel wrote:
| I hear your snark, but Reddit isn't exactly a beauty contest
| winner.
| makapuf wrote:
| Yeah I was thinking "but..." ah but yes I use
| old.reddit.com. well, case in point.
| xp84 wrote:
| I think it's funny that you think sites can't be attractive
| unless they include many megabytes of complex JS and CSS on
| every page. Craigslist lasted and was dominant a whole extra
| generation of the Web until Facebook Marketplace unseated it
| without even bothering with colors and certainly no
| animations. And FBM didn't win on clever animations and React
| UI complexity, it just won based on the fact that it was
| easier to detect Nigerian scammers since you can see when the
| buyer's FB account was created and a few other cues. Users
| don't care how clever your programmatic animations are. They
| hate how slow your site is. Look how much Jira sucks now.
| It's more sluggish on an M4 Pro than it was on my Core i5 in
| 2013 because of how much frontend bloat they've added in the
| meantime.
| filleduchaos wrote:
| This seems like a rather knee-jerk response to someone
| arguing that they can build _the same UI_ with less.
| jakubmazanec wrote:
| 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...
| xp84 wrote:
| Citation needed for 'GIFs don't scale well' (in terms of
| dimensions. They certainly don't scale well when abused as
| idiotic versions of videos.)
|
| Is this the frontend developer's version of "Postgres doesn't
| scale. Mongo is Webscale"?
|
| Here's a 640x640 GIF. Scales just fine for me, to half-size
| or to 100px. I'm using a "Retina" screen. https://cdn-icons-
| gif.flaticon.com/6172/6172533.gif
| Sharlin wrote:
| That GIF weighs one third of a megabyte. You could
| literally fit a fully featured bespoke 2D/3D rendering
| engine in the same space. Now, it could probably be
| optimized, but an aPNG would likely be vastly smaller. And
| these days aPNG is even reasonably widely supported! That
| said, an animated SVG would likely be the best option.
| supermatt wrote:
| I'm looking at that on an iPhone, and if I scale (in either
| direction, pinch or zoom) it I can see a semitransparent
| halo around it, I would assume from the antialiasing.
|
| So that certainly isn't scaling well for me.
| beejiu wrote:
| GIFs scale quadratically with their resolution and they
| don't even support an alpha channel, which makes them
| inflexible.
| panic wrote:
| Won't the GIF also burn a ton of CPU? I'm not convinced it
| would actually be more performant than sliding textures around.
| xp84 wrote:
| Try it yourself.
|
| Here is a _640x640_ gif: https://cdn-icons-
| gif.flaticon.com/6172/6172533.gif
|
| That tab is using 4-5% CPU on my M1 Pro, and I also have a
| "GPU process" in my task manager, which is showing about 8%
| in the "CPU" column when it's onscreen. So, no, using a 64x64
| GIF (1/100th the area of my example) you'd need to do this
| animation would absolutely not use any significant CPU or
| GPU. Which is why those worked very effectively to animate
| small icons with zero lag on the potato computers we had in
| 2000.
| MITSardine wrote:
| The app taking "only" 6% of a $3k laptop's CPU to show two
| lines of text and a little 2D animation also gave me pause, but
| maybe this is just how it is. Still I wonder how people were
| squeezing pacman out of prehistoric machines, and we're using
| an 80's supercomputer worth of CPU power (not that far given
| they were in the ~ 1 GFLOP range) to animate three green bars
| today.
| xp84 wrote:
| They actually knew how to code back then. I fancy myself
| someone who cares about performance and take a great effort
| to not do wasteful stupidity like those CSS animations for a
| decorative element, but compared to 80s programmers, I'm
| actually a complete fraud, because I do everything in
| interpreted languages that do 10,000 things behind the scenes
| for every line of code I write. I could never make an Atari
| computer or NES work.
|
| There are of course a few who do, they all either work on
| embedded systems or making homebrew for retro computers. So
| much respect for that level of skill!
| Varelion wrote:
| I aspire to be one who cares about performance, but I would
| like to address:
|
| " _I do everything in interpreted languages that do 10,000
| things behind the scenes for every line of code I write._ "
|
| Is it even possible to create a modern website, or product,
| without this? How long would the development cycle take, if
| everything is to be written in C?
|
| I'd wager that replicating a "minimalist styling" for a
| react-based website with a dozen or so components would
| take dozens of times longer to produce.
| drdec wrote:
| > How long would the development cycle take, if
| everything is to be written in C?
|
| Once upon a time I worked on a website backed by C.
| Development times were not appreciably longer.
|
| We had a in-house templating language for generating HTML
| (also written in C). That implementation got to the
| complexity point to where even the original devs did not
| want to touch it to add anything.
|
| But in terms of add a new screen collecting fields x,y,z
| it was fine. This was a job board, allowing search,
| applications, saved resumes, bulk opening uploads, i.e.
| there was some real functionality there.
| Varelion wrote:
| Interesting.
|
| If this is the case, I do wonder why we do not see more
| of this.
|
| Were you around for the original design phase? Why was C
| chosen? Did you and yours collect performance metrics to
| see if anything meaningful was gained?
| pixl97 wrote:
| C on the modern web would terrify me. Devs are bad enough
| with interpreted languages, I can't imagine most of them
| using a language with a howitser sided footgun.
| sampullman wrote:
| Why the embedded SVG hate? A simple icon should be just a few
| hundred bytes, is reusable, and styleable with CSS. It's not
| the right fit 100% of the time, but I think it's a very nice
| feature to have.
| zdragnar wrote:
| 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.
| makapuf wrote:
| 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.
| ajkjk wrote:
| 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 abstraction and so
| don't even think to go outside of it by default. Which would be
| fine, except that the abstraction isn't designed very well: the
| browser is massively underpowered at building applications in
| an foolproof way. Part of that is historical cruft and part of
| it is (imo) a lack of vision--there should have been a (not-
| backwards-compatible) replacement for html/js/css years ago
| which solves its fundamental abstraction problems.
|
| But anyway the present is still much better than the past. You
| must be nostalgic for the era when all monitors were the same
| size and websites weren't expected to do anything without
| reloading the page.
| bobthepanda wrote:
| 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.
| ajkjk wrote:
| Well they don't really. What ought to happen is someone
| just makes a new browser (or adds support in an existing
| browser) unilaterally on an experimental basis. If it's
| good enough I imagine it would catch on. The limiting
| factor is presumably that that's a lot of investment for an
| experiment, but getting anyone else on board without a
| successful experiment is going to be impossible. (well,
| also, you have to have a good enough plan to be worth
| switching. I don't think dart/flutter was that.)
|
| A nice starting place would be if one of the major browsers
| added an easy to use extension point for swapping out
| languages. (at least I'm not aware of this existing, nor
| that I've looked)
| callalex wrote:
| Dart/Flutter was never a technical issue, but a
| political/monopolistic issue. The underlying monopoly has
| not changed, so I don't really see a path forward unless
| the chromium team magically changes leadership.
| bobthepanda wrote:
| I guess my point is, if the big Chromium team couldn't
| pull something like this off, who else would? At this
| point major web updates tend to get born in one of the
| big tech companies funding web development, either
| directly or indirectly (Mozilla being funded by Google)
| ajkjk wrote:
| I personally don't think dart/flutter was good enough of
| a solution to be worth everyone's time. When this
| actually happens it will be more of a paradigm shift than
| that. That's why (which I said in the other comment) what
| needs to happen is that innovating in this space needs to
| become a lot easier.
| beejiu wrote:
| An engineer could build that much faster than it would take to
| build an animated GIF in an editor. (For a start, it's a much
| more complex animation than 6 frames.)
| pixl97 wrote:
| Embedded doesn't require a new tcp connection to the server and
| can be a speed up depending on a number of factors.
| verall wrote:
| 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.
| mrob wrote:
| Your browser should allow you to override all CSS on the web.
| Here's how I disable CSS animations in Firefox:
|
| https://news.ycombinator.com/item?id=33223080
| dleeftink wrote:
| A bookmarklet that injects custom CSS and selects all/certain
| items and applies the `contain: content` and `content-
| visibility: auto;` rules could do to trick.
|
| Additionally, the pseudo `:empty { display: none; }` selector
| may get you additional mileage.
| crazygringo wrote:
| Seriously. It seems pretty reasonable to allow a web page a
| total amount of processing that is something like 100% CPU or
| GPU for 5 seconds. (E.g. can be 25% for 20 seconds.) And beyond
| that it gets throttled to 3% CPU cumulative max for however
| long it's been open so far.
|
| And make that the default for popular browsers, so sites are
| forced to be efficient or else be super super janky and
| stuttering. And allow a permission for unrestricted processing
| that things like WebGPU demos or games can ask for.
| HWR_14 wrote:
| 100% of the CPU for 5 seconds seems unreasonably long for a
| random webpage.
| crazygringo wrote:
| 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.
| londons_explore wrote:
| ChromeOS has logic that restricts background tabs to 1% CPU use
| I think.
| rayiner wrote:
| They should put in something that allows users to electroshock
| web designers for wasting their battery.
| thway15269037 wrote:
| I don't think combined energy output of every power station
| on Earth would be enough after we have Electron apps for so
| long. (edit: typo)
| rayiner wrote:
| They should call the feature "Electron."
| orhmeh09 wrote:
| Yes, with StopTheMadness
| https://underpassapp.com/StopTheMadness/
|
| It works on Safari, Chrome, and Firefox, but you must buy it.
| barrkel wrote:
| It only works on Apple though it looks like.
| socalgal2 wrote:
| How about just not using that site?
| Varelion wrote:
| It seems beyond absurd to me, that this tiny animation should be
| costing as much as 6% of CPU.
|
| There has to be more optimal ways to do this.
| MITSardine wrote:
| So, the CRAY-2 built in 1985 was rated at 1.9 GFLOPS. The M2
| the author uses seems to be benchmarked at around 6GFLOPs per
| core [1]. So this 6% of the author's CPU (assuming charitably
| this is a single core) corresponds to about 20% of the mid 80's
| peak supercomputer capacity.
|
| People were already using those computers for applications that
| go slightly beyond animating 5 x 3 green little bars up and
| down at the time...
|
| I understand dev time cost > CPU time cost (for the company
| that hires the developpers anyways) but aren't things getting a
| little out of hand?
|
| Even without comparing to an 80's supercomputer, what if
| someone with a 15 years old laptop tries to use their app? What
| will those 6% CPU on the dev's shiny M2 MBP become?
|
| [1] https://boinc.bakerlab.org/rosetta/cpu_list.php
| utopman wrote:
| This.
|
| I did not find other comments like this in this thread.
|
| 6% M2 cpu (even single core) is a huge computing budget for
| such a small feature.
|
| At this point I don't really understand why OP seems happy
| with this result (sorry).
|
| I think even a naive canvas implementation can really and
| quite easily cut most of this computing budget.
|
| Also, a pure css animated thing should use mostly gpu in a
| right DOM implementation. I think some issues remains in this
| result.
|
| Maybe OP displays it's app on a 240hz external screen which
| makes browser compute DOM animation at 240 fps requiring
| slighly more compute in a passive way (4o-mini suggests this,
| I am not sure browser works like this)
|
| I remember too much of my pentium 1 166Mhz let run entire age
| of empires 2 game in 1997
| khalic wrote:
| Yeah it really helps knowing CSS when doing frontend dev...
| exiguus wrote:
| I'm not 100% convinced. Likely because the article doesn't show
| the difference between animations that are announced with 'will-
| change' and/or elements that are animated with position absolute.
| Also, it looks related to the browser and there was no evidence
| that this is also a issue in FF or Chrome.
| deepsun wrote:
| 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 <table>
| 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
| <table>.
| liuliu wrote:
| Thank you! This is what I am looking for in HN comments. Layout
| engine cannot be that stupid per the article. I guess it is not
| once you give it enough hint.
| codeptualize wrote:
| This is the answer. I thought this was fairly common knowledge,
| height is animated quite often (think dropdowns), no need for
| the over complications.
| alexchantavy wrote:
| Is there a good way to learn techniques like this from first
| principles other than trying to become an employed frontend
| dev?
| brokencode wrote:
| Usually you try to build something, realize it's slow, then
| do a combination of searching for possible solutions, trying
| them, and profiling again and again to gain this knowledge.
|
| Experience is the best teacher.
| legitster wrote:
| 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.
| bfgeek wrote:
| This likely more effective quite a few years ago, but not
| particularly important today.
|
| Changing height typically only shifts elements, and browser
| engines typically wont relayout them due to position changes.
|
| "overflow: clip" is also much more lightweight than "overflow:
| hidden"
| tristor wrote:
| Man, I hate what the web has become in 2025. There is absolutely
| no respect from frontend developers for their users. It's obscene
| the amount of wasted CPU cycles, energy, battery life, bandwidth,
| and time we have in aggregate due to horrible frontend
| development practices.
| DamonHD wrote:
| Not just front-end!
|
| https://www.earth.org.uk/RSS-efficiency.html
| mpliax wrote:
| > What is Granola spending those cycles on? It's an Electron app
|
| He could had stopped there.
| endemic wrote:
| 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
| Sharlin wrote:
| 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.
| jbeninger wrote:
| 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/
| Etheryte wrote:
| None of this should be esoteric knowledge if you work with web
| technologies for a living. Animations, box shadows and blurs
| have a very long history of performance issues. Similarly,
| standard tools easily highlight the issue, as shown in the
| article.
| awkward wrote:
| This looks like a clever implementation of a useful feature. I
| enjoyed that the developer was able to link the streaming audio
| API to a useful visualizer, recognize problems with his approach,
| debug issues in that visualizer, and find a clever solution using
| graphics fundamentals like masking.
|
| I'm less than impressed with the general consensus that he's
| somehow negligent for launching a feature that needed a fix, or
| that users don't want or need feedback about audio connectivity,
| or that the poster did something much better sometime back in
| `02.
| rectang wrote:
| I read this article because just last week I set up CSS height
| transitions to show/hide divs in a form which displays
| conditional content (based on radio button selection). "Why
| shouldn't I do this?", I thought.
|
| It looks like the point of this article is that you should avoid
| _continuous_ animation for CPU performance reasons. These
| performance reasons are probably inconsequential for occasional
| transitions.
|
| For many of us in the target demographic of "people who animate
| height", the scary title of this article is misleading.
| DamonHD wrote:
| I created a little CSS-pulsing 'live' button and give it a
| fixed number of cycles of pulsing to cap worst-case resource
| consumption. But it took me a while to work out that that was
| the right thing to do!
| Quarrelsome wrote:
| > Instead, we can create the illusion of a changing height by
| using two rectangles, applying translate to each.
|
| Its a very clever solution and props to the engineer, but this
| being the fix makes me truly despair at where we are as an
| industry around web UI. That html and css won despite these sorts
| of counter-intuitive horrors.
|
| UI layers that make me feel good reflect intent. I can take an
| image and write some code to darken that image (any image) and
| show that to the end user. It makes sense. However, in html+css I
| have to introduce a third element, another rectangle, slap it
| infront, paint it entirely black and set its opacity to something
| low. Sure, it works the same but it just feels so conceptually
| ugly.
| andoando wrote:
| I had a similar problem trying to animate a book flipping
| pages. At the half way point I had to update the text to show
| the backside and update the back pages.
|
| However no matter what I did, I could not get the update to
| sync correctly with the page being exactly half way. There's
| probably a solution but I just gave up
| lelandfe wrote:
| It's literally the sliding doors technique from, uh, two
| decades ago https://alistapart.com/article/slidingdoors/
| russellbeattie wrote:
| I'm not sure how it's implemented on the JS side, but I can
| imagine the CSS getting a lot of updates per second as the voice
| level changes, constantly interrupting the current animation.
|
| Might be worth it to buffer the input until animationEnd() event
| fires. That might reduce the amount of calculations and redrawing
| that needs to be done.
|
| Or the CSS engine is robust enough to handle continual updates
| and this won't solve a thing. I'd have to test it.
| rayiner wrote:
| Why do browsers even allow this shit. I was trying out a
| scheduling app the other day, and it was using 3% of CPU just
| sitting there doing nothing. That's a Pentium 1 level of
| computing power to do _jack shit._
| pharrington wrote:
| You can animate height without forcing a relayout, as long as the
| element is out of the document flow.
| Saris wrote:
| Why are the bars on a little button animated in the first place?
| I don't get it.
| deathanatos wrote:
| 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.
| calypso wrote:
| You're still okay with wasting 6% CPU and 1% gpu time on a simple
| note taking app?
| ASalazarMX wrote:
| In my wimpy work Virtual Desktop, this page eats 25-40% of my
| CPU just by scrolling up or down after fully loading. It's a
| severely limited VDI, I agree, but this performance is crazy
| for what is functionally a static page.
|
| It certainly doesn't give me confidence in using their app,
| given this landing page can become as heavy as GMail while
| doing nothing. How optimized is their electron app? Is the iOS
| version as heavy? Are they OK with wasting all this energy for
| nothing?
| forrestthewoods wrote:
| > It's an Electron app
|
| The worst modern invention. HTML/CSS is so bloody awful at
| rendering user interfaces. We should if at least contained it, if
| not killed it outright. But instead it's a contagion that has
| spread far and wide.
|
| How the hell does the optimized version use 6% of CPU? It should
| render at roughly 5000 frames per second.
|
| What a tragic state of affairs we live in.
| Ken_At_EM wrote:
| The final CPU/GPU usage is still totally unacceptable.
| irrational wrote:
| Wouldn't the real fix be to use an animated gif?
| echoangle wrote:
| I think the idea is to have the animation respond to the actual
| volume in realtime. The animation property is only so that the
| 10 updates per second get interpolated according to the
| framerate, I think. The real solution would be to remove the
| gimmicky animation and show a red circle.
| 65 wrote:
| This article doesn't apply to every single use case and should
| not be taken purely at face value.
|
| A few week ago I needed to animate height for a banner like
| message that appeared in the layout (e.g. it was not absolutely
| positioned) once a user clicked a button. This banner message
| would cause a layout shift no matter what because its height was
| being added to the layout and shifting the elements underneath it
| down. Thus, to mitigate a jumpy layout, making the height animate
| made the layout shift easier on the eyes.
|
| And before you say "well design it differently" - I didn't design
| this.
| tomaskafka wrote:
| How about we create tools that don't consume 5+ % of user's CPU
| (and keep it busy, not allowing it to sleep, decreasing battery
| life significantly) when idling or doing some background work?
___________________________________________________________________
(page generated 2025-07-22 23:00 UTC)