[csswizardry]

I used to share this sentiment (and I’m a web performance consultant by profession so very few people care about performance as much as me!), but when you consider how much calculation we _happily_ let our JS do at runtime, I don’t think forcing CSS to be static/preprocessed is worth it. And that’s not even me taking a swipe at overly-JSsed front-end; I’m talking about any runtime work that JS picks up.

Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.

[dleeftink]

An optimisation I've always wondered about for transforming/translating/animating elements: is it faster to use JS translations or animation API directly on the element (e.g. style.transform / element.animate), or updating CSS variables with JS to let the CSS engine reposition inheriting elements?

In the context of animations, I'd intuit the latter but would be open to hearing why.

[Sesse__]

You want CSS transitions or animations, since they can run on the compositor thread (most of the time). Zero jank.

(I work with CSS browser performance, although animations is not my primary field)

[cluckindan]

jQuery has .animate() which uses the JS API and used to be very popular. When CSS Animations became available, that part of jQuery became obsolete overnight.