[mattgperry]

Most CSS animations aren't hardware accelerated. Only a few values like opacity and transform.

Updating the DOM (as in innerHTML) is always expensive because it triggers layout. This is true whether you're doing it from JS or a CSS trick like on this page.

Finally this approach is using CSS custom properties. These are slow - slower than JS for most things.

If you stop all animations on this page and profile it via Chrome you can see this in effect. The root node is animating a CSS variable. 117 elements have their style recalculated. Every frame - yet no animations are running. There's also a tiny paint triggered too, obviously there's been no changes so it is tiny in this instance, but a paint is always triggered when a CSS variable updates.

This is why animating x and y separately via CSS and a style like `translate(var(--x) var(--y))` would be worse than animating them via JS ala Framer Motion/GSAP.

[amsheehan]

We shouldn't diminish the power of transform here. It's not just one property like opacity. You can animate quite a bit on the compositor with transform

[agust]

Just one nitpick: the DOM is not updated by CSS here, only the value of the CSS variable is. (It will indeed cause style recalc and paint though, and result in poor performance as we can see with the demos.)

[SirHound]

Yeah true tho I’m referring to the counter being set via the content style, which doesn’t update the DOM as such but does/can change layout