3 ms·
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 consi
by csswizardry 1y ago
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 1y agoAn 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__ 1y agoYou 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 1y agojQuery 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.