components and templates with Framer Motion

Variants are the feature that changes how you write animation, and most people skip them. Instead of giving every child its own animate prop, you name states on a parent, say hidden and visible, and children inherit them by name. Add staggerChildren to the parent transition and a list animates in sequence with no timers and no index maths. The payoff grows with the size of the component: a navigation menu with eight items becomes two objects and a loop rather than eight hand-tuned delays.

Layout animation is the other feature that is hard to reproduce by hand. Add the layout prop and Motion measures the element before and after a change, then animates the difference using a transform, which is why it stays smooth even though width and position moved. Pair it with layoutId on two different elements and you get the shared element transition people associate with expanding cards and image lightboxes. The caveat is that layout animation reads from the DOM, so it is measurably more expensive than a plain opacity fade. Use it where the movement carries meaning, not on every card in a grid of forty.

For gestures, whileHover, whileTap, whileInView and drag cover almost everything without state management, and they clean up after themselves when the pointer leaves, which is the part hand-rolled hover state usually gets wrong. Two things to remember: whileHover does nothing useful on touch devices, so never hide information behind it, and whileTap should be subtle, around a 0.97 scale, because a large tap animation reads as lag rather than feedback. If a control is a real button, keep it a button element so keyboard and screen reader behaviour survives.

Spring versus tween is a question about what the movement represents. Springs are defined by stiffness, damping and mass rather than a duration, and they suit anything the user initiated, since the slight overshoot reads as physical. Tweens have a fixed duration and easing curve, which is what you want for entrances and fades, or for anything that has to finish in step with something else. A common mistake is a bouncy spring on a page load animation, where the overshoot makes content look like it is settling into place late. Springs also complicate orchestration, because you cannot promise a spring will be done in 300 milliseconds.

The performance rule is short. Animating transform and opacity is cheap because the compositor can do it without touching layout or paint. Animating width, height, top, left, margin or box-shadow forces the browser to recalculate on every frame, and box-shadow in particular is a known frame killer at large blur radii. Substitutions exist for most cases: scale instead of width, x instead of left, y instead of top, and a pre-rendered shadow layer whose opacity you animate instead of the shadow itself. Test on a throttled CPU in devtools rather than on your laptop, because the machine you build on is the least representative device in the chain.