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.
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.
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.
Or there are images being used in the canvas, which would defeat the purpose for the use case you described.
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.
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.
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.
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?!
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.
contain: strict;
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.
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
You know what else was a waste of electrons? Your comment, and my reply.
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.
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.
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.
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?
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.
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.
For that matter, do we really need colors? Just ship it with browser default styles.
[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...
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
So that certainly isn’t scaling well for me.
In the broader sense, especially in the 'flat design' era where we don't use gradients or complex backgrounds anywhere, a 256-color GIF with its 1-bit alpha (plain transparency) will work perfectly fine to do an animated flat non-3d, non-photorealistic icon that wiggles or whatever, on a background that is almost certainly a plain flat color, and not complex enough to need 16 million shades of transparency.
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.
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!
"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.
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.
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?
The architecture involved a custom Apache httpd module to handle requests. That most likely drove the decision to use C.
The system was eventually rewritten in Python, after I had moved on.
I'm not aware of any performance metrics.
In particular I remember one bug where a pointer to a local variable was returned by a function. It worked on our development environment which was apparently more forgiving than our production environment.
Why were they different? Because they were actual servers and the production one was the expensive DEC Alpha while the development server was something less expensive (my memory fails me as to the exact machine).
Another way to look at it, is only those who could write very optimized code could get anything meaningful running on those machines. Hence all (?) software from far enough back was optimized down to death.
I'm personally grateful I've never had to wrangle hardware bugs into features and other such hacks one stumbles upon in anecdotes from those eras... even though there is a certain charm to it all.
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.
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).
Please write a nodejs server that produces those tiny images, don't forgot to correctly set the caching headers...
99% of the inline <svg> usages I see are people using js includes to inline an SVG which is itself stored in a .jsx file. This is just as lazy and wasteful as it would be if Styled Components were built not to generate classnames and a single stylesheet, but instead with all the rules simply inlined in style attributes on every element.
For really simple ones, the size of the icon isn't a whole lot bigger than a CDN/object storage URL. And if you reuse it a couple times, it might even be a net bandwidth reduction.
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.
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)
What would that actually mean in practice that would be different from how Dartium did it?
Such that one could throw together, I dunno, news.ycombinator.com/index.z and see if they can do a better job than HTML/CSS.
As far as the actual solution to try for, table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch).
What would be the use of that? It would help people who want to make prototypes of a different web with no hope of it ever getting adopted, but that's not a huge market.
> table stakes is a native implementation of something that looks like React (but presumably reimagined from scratch)
Like a component layer? Browsers have tried with e.g. XUL or WebComponents, how would you avoid the problems of those?
So people can experiment with it. Creating a good place to experiment is the best way to make lots of good ideas happen. If 10000s of people can play with ideas instead of the 10 groups with enough time and energy and expertise, you get a much richer exploration of the space. Heck if it was easy I'd be doing it right now.
> Like a component layer?
I'm not aware of anyone creating a component layer that is even passable for abstraction compared to React's programming paradigm. Usually because they stay imperative-first when all signs seem to point to declarative-first being the more scalable model.
> how would you avoid the problems of those?
Umm... they're terrible, so I would just not copy them? Look at XUL for seconds and try not to vomit. WebComponents adds abstraction of HTML in Javascript, rather than in HTML / declaratively, which is obviously never going to work as a foundational technology. It is far too imperative-first. I would start by copying React... but then doing everything differently because most of React's design is forced by being implemented in JS and having to work around CSS being quirky. The greenfield version would do a much better job.
(This is not any better solution than GIF or aPNG though for the problem in the article.)
The animation (which is not suppose to be constant/static) conveys whether audio is being picked up by the application. I.e., it's VU meter.
Its meter, not "it's". Its means possession, it's is a contraction that means "it is"
> 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).
For most use cases … that's all that's necessary? It helps confirm that the audio equipment and various software layers are working.
… like I use these UI elements all the time, because Bluetooth has decided that "nah, I'm not going to connect, even though every device reports as connected".
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.
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.
Sure, noodling with content blockers has its own advantages, but for this particular case they cut at the wrong abstraction matter.
Additionally, the pseudo `:empty { display: none; }` selector may get you additional mileage.
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.
My suggestion wasn't really about promoting maximum best practices, but just avoiding total runaway excess.
Websites don't need that much resources and should be optimized.... if somehow web developers could read, maybe they'd start doing that.
For 99% of the people, word 97 was good enough then and is still good enough now to do whatever they need. They can literally still use it today. (yes yes, docx compatibility, i'm just making an example).
Web stuff is one of the few things where the amount of useful data on an eg. weather report site (webmail, news site, bus timetable site,...) hasn't changed, the cpu requirements have gone way way higher for no useful reason (except to serve more ads), and the users can't use the "old versio" of the site anymore. It's literally gigabytes of ram and multiple seconds of 100% cpu usage to service 5kB of article text and a 50kB article photo.
[1]: https://searchfox.org/mozilla-central/source/browser/modules...
It works on Safari, Chrome, and Firefox, but you must buy it.
I'm with you 100%. Although I'd go one step further and say CSS just isn't needed at all, and should be removed from all browsers. Same goes for WebGL (if you want to play a game, download Steam).
This would fix all of your issues and save an unbelievable amount of energy across the planet. Unfortunately people like us are a dying breed!
There are some situations where having some animation can "attract attention" to parts of the UI, for guidance ("there's some info text here"), feedback ("operation complete"), state changes, timing. All this of course doesn't apply to decorative animations.
With that said: a lot of the situations I mention above are manufactured. They are often because of changes happening away from the mouse, or because the interface is brittle or too slow, and the user doesn't have confidence that something really happened, or because the organization of elements is not functional and things are too far apart that the user might miss something in a totally different part of the screen.
IMO, with enough thinking you can come up with alternative interfaces that don't require animations at all.
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.
Basically, animation provides additional information about object state. Removing that extra information increases cognitive load.
This isn't to say all animations are useful. Many animations are excessive or completely unnecessary, which is probably what has given you a negative view of them.
Quite unreliable and more a joke than anything, of course...
!Disable CSS animations globally
*,com##*, ::before, ::after :style(animation-timing-function: step-start !important;transition-timing-function: step-start !important)
!Disable text shadow globally
*,com##*, ::before, ::after :style(text-shadow: none !important)
!Disable image filters globally
*,com##*, ::before, ::after :style(filter: none !important)
!Disable rounded corners globally
*,com##*, ::before, ::after :style(border-radius: 0px !important)There has to be more optimal ways to do this.
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?
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
That's still a lot for a single page IMHO, but it seems that service is doing resource expensive things in the first place.
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>.
Experience is the best teacher.
the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.
my criticism is reserved for the concept of "first principles", as if there should be a cohesive and simple set of rules that you can build up all the knowledge you need from. that's just not really how any complicated system works: building a comprehensive understanding of a complicated system takes a lot of work and a lot of time.
Have you never resized a window on a desktop OS?
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.
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"
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'"?
These are not hyperspecific examples. We're literally discussing under an article which has a primitive animation which was, quote, "using 60% CPU and 25% GPU on [a] M2 MacBook"
How is 2D graphics programming helping there?
The article goes on to describe, correctly, layout properties ("The W3C spec is full of these!"), paint properties ("this tiny "bikeshed" SVG which you can find on lots of W3C spec pages. It costs ~30% CPU!") and composite properties.
These are not specific examples. These are literally footguns upon footguns that literally have no corresponding counterpart anywhere.
> That doesn't mean that understanding what is typically happening is useless. Which is essentially what your claim is.
Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
No we are not. Someone asked about how one learns some techniques that the OP mentioned (that were simpler than the ones given in the article). I gave some general advice on how one should think about what is happening and some general advice about how to think about performance.
Then you are pretending that none of this is relevant because you are concentrating on the hyper specific stuff in the article (which we are no longer talking about).
I also disagree that this cannot be reasoned about by learning a bit about how graphics works, Cartesian coordinate system and literally turning on the paint flashing tool that is in dev tools. It is literally obvious what is happening when you see it.
> Yes, knowing 2D graphics programming is 100% useless to understand what's happening with CSS and DOM.
In fact it was very helpful to help me to understand what was happening. I literally said to myself "wait a minute, that is kinda like this thing I did in SDL 1.2 in university". You are literally telling me, that something I know to be useful isn't, because you say so. That is unreasonable.
Yes. Yes we are literally discussing this under an article whose introduction literally says what I quoted.
> Someone asked about how one learns some techniques that the OP mentioned
Yes, and the techniques OP mentioned literally cannot be learned from 2D graphics because nowhere in 2D graphics are you going "ah yes, to fix 60% CPU utilization for a primitive animation, you need to apply this awkward workaround that will tell the browser not to reflow the page".
Edit: and this particular technique is only applicable to this specific property for reasons that do not exist anywhere else, except in the browsers.
> wait a minute, that is kinda like this thing I did in SDL 1.2 in university
Well, it's not. Just because it kinda somewhat looks like something different doesn't make it so. Hence my question in this comment: https://news.ycombinator.com/item?id=44658482
Because those are not hyper specific, no matter how much you pretend they are
So the you need to fix that height /remove resize, then google on which technique to use?
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.
Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.
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 - 1% when no interactions are taking place.
I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there.
Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).
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.
It's frustrating how just changing a filtering option will reload the entire web page on most websites.
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"
Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!
> Just wrap it in a container with fixed height and "overflow: hidden".
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.
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.
He could had stopped there.
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.
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.
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.
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.
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.
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
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.
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.)
Not to mention how much dB as a unit freaks people out.
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?
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.
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.
The UI of this app literally only has a piece of text, a button and this animated indicator. To render this it needs an entire chromium browser loaded into memory, and still it has performance issues.
I will always prefer software written in native graphics toolkits. I understand the benefits of using electron but the only electron based software I've ever liked was vscode.
> Less expensive are paint properties. A paint property does trigger layout, but it does repaint a layer, and then re-composites.
It doesn't trigger a layout step?
--
Damn, is this 6% of the whole CPU?!
1. making a note-taking app in 2025: 1st mistake. cuz well solved space with great existing tools/options going back to the 80s/90s
2. as a GUI
3. with animations (in a note taking app?!)
4. in a browser
There, I fixed it. I have a custom CSS that kills all animations whenever I'm forced to use a "modern" browser, and it definitely tames the web.
From my first try, I immediately had the performance monitor visible because I knew this could be RAM intensive.
I iterated a few times until I settled on SKIA and boy, the performance was night and day.
Looking at the animation, I'd wager it's still way too much CPU use for what it is.
How can the browser know if an arbitrary animation can change an element's height? I'll bet 10 bucks this is equivalent to halting problem.
Unless you 1) don't support full SVG spec or 2) separate SVG elements from the layout completely, it's not a problem that is solvable by browser. The developers need to wrap their animation in a fixed size element and it's very reasonable to expect them to do so.
Plus, the CSS spec doesn't prevent browser vendors from optimizing this specific use case if it's really that needed.
(Of course in the case of this simple web app in OP, the correct solution is to not use animation at all.)
Ouch. All of this for a tiny visualizer animation.
> 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%).
This still feels way too much compute for a tiny animation updating a couple times a second.
Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
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.
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.
I usually develop my apps on a 1300 MHz single-core Intel Atom mini PC from 10 years ago. When something like this goes wrong, the app becomes unusable and I immediately notice it.
andrewstuart•6mo ago