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.
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.
Firefox already has a monitor module that AFAIU tracks UI stalls and prompts the user to stop the website if it hangs for a long period [1]. It probably can be further developed to also track resource consumption and show a warning if some threshold is reached.
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.
> 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.
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!
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>.
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.
Well, and especially because the “fixed” version is still - if I’ve read correctly - 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 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).
A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.
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!
Translation: just make a completely different functionality and effect than what was originally intended because the DOM can only handle static content, barely.
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.
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.
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.
> If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.
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"
Not sure, but if CSS first principle is parent sets width going down to children, but sets height going up from children, then you could see how children changing its height leads to layout recalc all the way up.
So the you need to fix that height /remove resize, then google on which technique to use?
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.
not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes.
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.
I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.
> 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%).
Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
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.
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
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.
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.
And it's sensitive to dynamic scaling as well, isn't it? So it's possibly not 60% of a core at max clock, but maybe of a core clocked to 800mhz or something.
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.
Does a note taking app need such an animation if apparently it's that easy to accidentally drain the users battery?
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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
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.
You can animate an absolute positioned div without it obviously altering what a normal person would call "the layout." That's not simple unless one is willing to dig very deeply into the how web browser rendering works. And really still not simple. Otherwise this article wouldn't have been written.
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.
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?
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?
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
> 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.
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.
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!
> 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%)
Ouch. All of this for a tiny visualizer animation.
The fact that this little animation can have such heavy performance impact tells us one thing: CSS design is flawed. That‘s it. That‘s the whole story.
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.)
I’d be interested to see the performance of the same visualizer in a canvas or animated svg instead. Forcing these animations through the dom seems a little absurd to me, but I’ve been surprised by web performance before.
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.
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...
CSS animations can sometimes cause weird performance issues or even crashes. 10 years back, animating box-shadow caused browsers to crash for our some of users by consuming a lot of memory: https://www.sheshbabu.com/posts/my-binary-search-debugging-s...
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.
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.
> 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.
Would the taskbar people be older people? There's something to be said about having a quick common place to get to the things you access the most. To that point, there are many many variations of launchers. I really wish webapps had taken off more, or having website create custom shortcuts for the various OSes so they can something like their red letter N logo on the desktop or wherever that just takes them to the website with a click rather launching the blue letter e then have to type something into a location bar or find it in some list of favorites. However, I think the sweet data analytics that apps allow companies to collect is too tempting and the web link just something to avoid.
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
Not just height, anything that causes continuous repaints can become expensive. Search for "jank free" to find more resources on the subject, or check this oldish website [1].
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?
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.
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.
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.)
… because it doesn't need to be bigger…? The purpose is to convey that "hey, the audio equipment is working". I use these all day to debug things like "am I not recording, or is the other side's volume muted?" We need "videoconferencing" or "notetaking" app levels of accuracy; it's not a sound studio app?
Not to mention how much dB as a unit freaks people out.
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.
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?
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.
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.
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.
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.
... 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.
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.
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.
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].
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.
What is your point? The random first GIF I found is enormous in pixel size and many frames, thus large in filesize, but a few dancing green blobs would be tiny. You don't need that one's 640px size to scale, and 2x will work perfectly fine.
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.
You really don't need an alpha channel for some tiny lineart thing such as the article's example. A single color would even be perfectly sufficient to make an attractive 'dancing bars' animation to indicate "sound is happening." That's my point. Some overpaid "UX designer" decided something wildly complex was needed here, and they're wrong.
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.
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.
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!
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.
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.
I didn't mean to suggest it would be practical to do the practical stuff people do today with Java, Ruby, Python etc -- web stuff or "app" stuff -- in say, 6502 assembly, or C. Just that doing a good job of the stuff contemporary to those in those languages (especially the 8-bit era stuff) is a tour de force in programming talent.
> 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.
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?
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.
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.
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.
Ok, I want to add a pencil icon here, the pencil should be #ccc, here is #ddd, there is rebeccapurple, and over here it should be the same color as the container color.
Please write a nodejs server that produces those tiny images, don't forgot to correctly set the caching headers...
Honestly, when people are making use of CSS to "reach into" the svg dynamically, or like your example, to color it dynamically, I'm not opposed to the strategy.
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.
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.
Believe me, a few kb on every icon on every pageview adds up to a lot of wasted bandwidth and not everyone is on a gigabit connection at all times, even fancy iPhones are on shitty connections a lot more than you think. Inside parking garages, on deprioritized LTE, etc.
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).
> 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. […] 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 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.
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, 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".
An icon served from an <img> is going to be served from browser cache (disk or even RAM) after the very first time it's encountered. Unless you're building something designed to be used for one visit ever (maybe a promotional landing page?) it's better to have a few more requests (HTTP2 especially makes this a non-issue anyway) and have a cache full of assets than to make your dynamic webpages bloated.
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.)
Does it need to be more than 6 frames to serve its purpose? It's 3 wiggling bars to be stuck into a 1/4 inch spot inside a button to serve a purpose of communicating a boolean state (sound happening or not?). The artist who actually designed that probably spent an hour plus getting it just right, wasting a ton of time before the engineer even wrote the "clever" GPU-destroying CSS, and then he had to rewrite the second version after discovering how resource-wasteful the first version was.
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.
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.
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)
> 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?
Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page.
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).
> 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.
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?
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.
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)
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.
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.
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.
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
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.
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.
> 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.
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.
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.
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.
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.
100% of the CPU for 5 seconds seems unreasonably long for a random webpage.
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.
Firefox already has a monitor module that AFAIU tracks UI stalls and prompts the user to stop the website if it hangs for a long period [1]. It probably can be further developed to also track resource consumption and show a warning if some threshold is reached.
[1]: https://searchfox.org/mozilla-central/source/browser/modules...
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
This is a level too deep. I don’t want to dictate what a website can and can’t do to limit resource usage; I just want to limit resource usage.
Sure, noodling with content blockers has its own advantages, but for this particular case they cut at the wrong abstraction matter.
They should put in something that allows users to electroshock web designers for wasting their battery.
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)
They should call the feature “Electron.”
Well, now you know where the name came from.
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.
Yes, with StopTheMadness https://underpassapp.com/StopTheMadness/
It works on Safari, Chrome, and Firefox, but you must buy it.
It only works on Apple though it looks like.
ChromeOS has logic that restricts background tabs to 1% CPU use I think.
How about just not using that site?
I wish. But some sites we are stuck with. EG: bank, HR App, etc.
How about not living in society and instead going into the wild?
Yes, because we should never ever try to improve the society we live in. Our only options should be to a) run away, and b) shut up and take it.
> 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.
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!
No css at all is pretty extreme, but I'd be on board with disabling css animations
That's very very sad. Animations can make UX much better when used correctly.
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>.
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.
Well, and especially because the “fixed” version is still - if I’ve read correctly - 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 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).
I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.
`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.
https://developer.mozilla.org/en-US/docs/Web/CSS/contain
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!
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"
This is the answer. I thought this was fairly common knowledge, height is animated quite often (think dropdowns), no need for the over complications.
Translation: just make a completely different functionality and effect than what was originally intended because the DOM can only handle static content, barely.
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.
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.
> If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well.
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"
Not sure, but if CSS first principle is parent sets width going down to children, but sets height going up from children, then you could see how children changing its height leads to layout recalc all the way up.
So the you need to fix that height /remove resize, then google on which technique to use?
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.
not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes.
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.
I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.
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.
> 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%).
Wait, this is supposed to be an improvement? 6% CPU for a lame animation?
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.
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.
I was just starting a comment on this but you beat me to it! I believe
on the parent element would have been sufficient here.I tested `contain: strict` on their color changing SVG and didn't see any difference. Profiler says it's still doing layout.
You tried the fix for height recalculation on the SVG that is changing fill and stroke and it didn't fix the issue? I wonder why
A lot of armchair suggestions here, but no benchmarks provided. Thanks for actually testing!
> On my M2 MacBook, the renderer process is now using 6% CPU
Looking at the animation, I'd wager it's still way too much CPU use for what it is.
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
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.
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.
And it's sensitive to dynamic scaling as well, isn't it? So it's possibly not 60% of a core at max clock, but maybe of a core clocked to 800mhz or something.
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.
[dead]
Videos game rarely do any complex dynamic layout. That is where all the time is going
Does a note taking app need such an animation if apparently it's that easy to accidentally drain the users battery?
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.
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.
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.
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.
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.
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
This was true pre iOS 18. The bars respond to the music now (at least on iOS)!
Ah, look at that, so they do!
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.
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.
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
Or if you need to actually control it, an SVG or <canvas> based animation
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.
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.
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.
> 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.
It’s literally the sliding doors technique from, uh, two decades ago https://alistapart.com/article/slidingdoors/
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
It's like building a space station with sticks and rocks.
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.
You can animate an absolute positioned div without it obviously altering what a normal person would call "the layout." That's not simple unless one is willing to dig very deeply into the how web browser rendering works. And really still not simple. Otherwise this article wouldn't have been written.
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.
But it wasn't expensive twenty years ago. Twenty years ago people actually knew how to efficiently use their limited computational resources.
so it wasn't expensive because people didn't do it? They did.
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?
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.
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
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
I did find a comment like this. It's dead
https://news.ycombinator.com/item?id=44653068
I assume 6% is for the whole page.
That's still a lot for a single page IMHO, but it seems that service is doing resource expensive things in the first place.
The final CPU/GPU usage is still totally unacceptable.
Cool article!
> 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.
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.
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!
> 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%)
Ouch. All of this for a tiny visualizer animation.
The fact that this little animation can have such heavy performance impact tells us one thing: CSS design is flawed. That‘s it. That‘s the whole story.
It really isn't.
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.)
I think there's a typo?
> 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?
I’d be interested to see the performance of the same visualizer in a canvas or animated svg instead. Forcing these animations through the dom seems a little absurd to me, but I’ve been surprised by web performance before.
dumb question: would putting the parent div in absolute positioning solve the compositing?
It already was. The whole point of this is that any height change is part of an expensive phase of the rendering pipeline.
Seems like a great use case for a tiny canvas instead.
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.
I recently created a voice notes app in react-native / expo. And I have a waveform that updates according to the multimeter (audio input)
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.
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?!
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...
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).
I strongly doubt its ability to render a fast rounded rectangle needed that.
CSS animations can sometimes cause weird performance issues or even crashes. 10 years back, animating box-shadow caused browsers to crash for our some of users by consuming a lot of memory: https://www.sheshbabu.com/posts/my-binary-search-debugging-s...
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.
Excellent dive that covers a bunch of stuff, thanks for this. The brevity, tho. Masterful and very appreciated
Is the information conveyed by this animation actually useful?
"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
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.
You could have a very, very long exchange of wasted electrons here to be in the scale of an Electron app starting up.
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.
> 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.
Would the taskbar people be older people? There's something to be said about having a quick common place to get to the things you access the most. To that point, there are many many variations of launchers. I really wish webapps had taken off more, or having website create custom shortcuts for the various OSes so they can something like their red letter N logo on the desktop or wherever that just takes them to the website with a click rather launching the blue letter e then have to type something into a location bar or find it in some list of favorites. However, I think the sweet data analytics that apps allow companies to collect is too tempting and the web link just something to avoid.
Do you have that documented somewhere, or is it just your observation?
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
> Don't animate
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.
Not just height, anything that causes continuous repaints can become expensive. Search for "jank free" to find more resources on the subject, or check this oldish website [1].
--
1: http://jankfree.org/
> On my M2 MacBook, the renderer process is now using 6% CPU
Damn, is this 6% of the whole CPU?!
You’re still okay with wasting 6% CPU and 1% gpu time on a simple note taking app?
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?
Wouldn’t the real fix be to use an animated gif?
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.
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.
Yeah it really helps knowing CSS when doing frontend dev...
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.)
Man at that point why not make it bigger and put a proper dB scale on it, at least it would be useful then.
… because it doesn't need to be bigger…? The purpose is to convey that "hey, the audio equipment is working". I use these all day to debug things like "am I not recording, or is the other side's volume muted?" We need "videoconferencing" or "notetaking" app levels of accuracy; it's not a sound studio app?
Not to mention how much dB as a unit freaks people out.
Except that it's not an actual meter, it's just a fake animation.
… we don't know this, and I'm willing to extend the article the benefit of the doubt, because it isn't relevant to the core of the article.
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.
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?
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.
> 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.
I seem to recall reading that Chrome has height transition optimizations coming.
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.
You can animate height without forcing a relayout, as long as the element is out of the document flow.
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.
... 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...
The product makes notes from the transciptions, so this animation isnt wildly off base to have
Transcribed voice notes
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.
Not just front-end!
https://www.earth.org.uk/RSS-efficiency.html
I love all things perf but stopped reading pretty early once I saw enough foundation mistakes (after which all else is folly anyway, haha):
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
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.
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...
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
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.
What is your point? The random first GIF I found is enormous in pixel size and many frames, thus large in filesize, but a few dancing green blobs would be tiny. You don't need that one's 640px size to scale, and 2x will work perfectly fine.
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.
GIFs scale quadratically with their resolution and they don't even support an alpha channel, which makes them inflexible.
You really don't need an alpha channel for some tiny lineart thing such as the article's example. A single color would even be perfectly sufficient to make an attractive 'dancing bars' animation to indicate "sound is happening." That's my point. Some overpaid "UX designer" decided something wildly complex was needed here, and they're wrong.
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.
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.
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!
Necessity is the mother of invention!
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.
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.
I didn't mean to suggest it would be practical to do the practical stuff people do today with Java, Ruby, Python etc -- web stuff or "app" stuff -- in say, 6502 assembly, or C. Just that doing a good job of the stuff contemporary to those in those languages (especially the 8-bit era stuff) is a tour de force in programming talent.
> 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.
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?
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.
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.
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.
Ok, I want to add a pencil icon here, the pencil should be #ccc, here is #ddd, there is rebeccapurple, and over here it should be the same color as the container color.
Please write a nodejs server that produces those tiny images, don't forgot to correctly set the caching headers...
Honestly, when people are making use of CSS to "reach into" the svg dynamically, or like your example, to color it dynamically, I'm not opposed to the strategy.
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.
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.
Believe me, a few kb on every icon on every pageview adds up to a lot of wasted bandwidth and not everyone is on a gigabit connection at all times, even fancy iPhones are on shitty connections a lot more than you think. Inside parking garages, on deprioritized LTE, etc.
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).
> 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. […] 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 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.
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, 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".
Hey, grammar police here. The animation is supposeD, like in "watcheD" not "watche".
Its meter, not "it's". Its means possession, it's is a contraction that means "it is"
Embedded doesn't require a new tcp connection to the server and can be a speed up depending on a number of factors.
An icon served from an <img> is going to be served from browser cache (disk or even RAM) after the very first time it's encountered. Unless you're building something designed to be used for one visit ever (maybe a promotional landing page?) it's better to have a few more requests (HTTP2 especially makes this a non-issue anyway) and have a cache full of assets than to make your dynamic webpages bloated.
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.)
Does it need to be more than 6 frames to serve its purpose? It's 3 wiggling bars to be stuck into a 1/4 inch spot inside a button to serve a purpose of communicating a boolean state (sound happening or not?). The artist who actually designed that probably spent an hour plus getting it just right, wasting a ton of time before the engineer even wrote the "clever" GPU-destroying CSS, and then he had to rewrite the second version after discovering how resource-wasteful the first version was.
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.
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.
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)
> 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?
Well I don't know how dartium did it really, but it seems to me like "add a new website implementation language to Chromium" would be a tutorial on Chrome/Chromium's home page.
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).
> 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.
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?
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.
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)
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.
Won’t the GIF also burn a ton of CPU? I’m not convinced it would actually be more performant than sliding textures around.
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.
[dead]
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.
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.
I hear your snark, but Reddit isn't exactly a beauty contest winner.
Yeah I was thinking "but..." ah but yes I use old.reddit.com. well, case in point.
This seems like a rather knee-jerk response to someone arguing that they can build the same UI with less.
Exactly this! I wish the entire web was easier to read on my e-ink device.
> What is Granola spending those cycles on? It's an Electron app
He could had stopped there.
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
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.
> 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.
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.
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.
We're working on this within Chrome DevTools, similar to an MCP server with the signals you're describing.