5 ms·

Don't forget that CSS animations are hardware accelerated. If you're doing trig in JS for animations, you're probably also manipulating the DOM to update the UI

Don't forget that CSS animations are hardware accelerated. If you're doing trig in JS for animations, you're probably also manipulating the DOM to update the UI every millisecond, which is very expensive

mattgperry 2y ago
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.
- agust 2y ago
  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 2y ago
    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
- amsheehan 2y ago
  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
pax_americana 2y ago
If you’re doing animations in JS, better do it with the Web Animations API since it’s also hardware accelerated.

mattgperry 2y ago

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.

agust 2y ago
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 2y ago
  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
amsheehan 2y ago
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

pax_americana 2y ago

If you’re doing animations in JS, better do it with the Web Animations API since it’s also hardware accelerated.