For a while, any animated hover state on a button meant a jQuery mouseenter/mouseleave pair calling .animate(). Now that transition support has landed in the browsers most of our clients' visitors actually use, we're moving a lot of that logic into CSS instead.
- transition: all 0.2s ease; on the base state, no JavaScript required for the animation itself.
- Toggle a class with jQuery when we do need JS-driven state, like an open/closed accordion or an active navigation item, and let CSS handle the actual animating rather than jQuery calculating intermediate frames.
- Fallback is simply no animation on older browsers that don't support transitions, which is an acceptable degrade for a hover effect, the interaction still works, it's just instant rather than eased.
Why this is worth the switch
It's less code, it runs smoother on the machines we've tested on, noticeably so on some of the lower-powered laptops a couple of our own team members still use for testing, and it means one less thing for jQuery to manage on pages that already have a lot going on, image galleries, form validation, a mobile nav toggle, all competing for the same thread.
CSS transitions are handled by the browser's own rendering engine rather than JavaScript recalculating styles on a timer, which is the real source of the smoothness difference. jQuery's .animate() works by manipulating style properties directly on a timed loop, which is a heavier way to get to the same visual result.
Where we're keeping jQuery for now
Anything with more complex sequencing, several elements animating with different delays relative to each other, or an animation that needs to trigger a callback partway through, is still easier to reason about with jQuery's animation queue than trying to coordinate multiple CSS transition-end events by hand. We're not treating this as CSS replacing jQuery animation everywhere, just for the large, simple category of hover and toggle states that make up most of what we actually build for clients.
It's a good example of a broader shift we're noticing this year, reaching for CSS to do more of what used to require JavaScript by default, simply because the platform itself has started catching up to what we needed a library for a couple of years ago. We expect that shift to keep going, and we're trying to stay in the habit of checking whether something newly possible in CSS has quietly made a chunk of our jQuery code unnecessary before reaching for the familiar plugin-based way of doing it.