Animations & Transitions (CSS + Framer Motion)

The big picture (read this first). Animation is just changing a value over time and letting the browser paint the in-between frames — ideally 60 of them per second, one every ~16.7ms. Everything about doing it well reduces to two questions: (1) what property are you animating (which decides whether the browser can do it cheaply on the GPU or has to redo expensive layout every frame), and (2) how does the value change over time (the timing — easing curves vs. physics springs). Get the property right and almost anything is smooth; get it wrong and even a tiny animation janks.

The cost ladder — the one rule that matters. Browser rendering runs layout -> paint -> composite. Animating transform (translate/scale/rotate) and opacity touches only the composite stage: the element is already on its own layer, so the GPU just re-transforms or re-blends the existing bitmap — no layout, no paint, buttery 60fps even while the main thread is busy. Animating geometry (width, height, top, left, margin, padding) forces reflow every frame: recompute layout, repaint, recomposite — which cascades to other elements and janks. Animating color/background is in between (repaint, no reflow). The golden rule: animate transform and opacity, never top/left/width.

CSS transitions — animate a state change. A transition interpolates a property when its value changes (usually on :hover, :focus, or a toggled class). You declare transition: transform 0.25s ease, opacity 0.25s ease and the browser animates whenever those properties change. Transitions are perfect for enter/leave-on-toggle and micro-interactions because they're declarative, need no JS, and stay on the compositor when you transition transform/opacity. You can't loop them or define intermediate steps — for that you need keyframes.

CSS keyframes — animate a timeline. @keyframes define named waypoints (0%, 50%, 100%) and animation: pulse 1.2s ease-in-out infinite plays them, with control over duration, iteration count, direction, delay, and fill mode. Keyframes handle looping, multi-step, and self-starting animations (spinners, pulses, attention cues) that transitions can't. Same performance rule applies: keep the animated properties to transform/opacity.

Easing: the shape of time. Easing maps linear time to a progress curve so motion feels natural rather than robotic. linear is constant speed (mechanical); ease-in accelerates (good for exits); ease-out decelerates (good for entrances — feels responsive); ease-in-out does both. cubic-bezier(...) defines a custom curve. As a default, ease-out for elements entering feels snappy because it starts fast and settles gently.

Tween vs spring — two models of motion. A tween animates over a fixed duration along an easing curve (300ms ease-out): predictable and repeatable, best for UI transitions where you want consistent timing. A spring is physics-based — you specify stiffness, damping, and mass, and the motion has no fixed duration; it settles naturally and can subtly overshoot, which feels organic and interruptible. Springs shine for gestures and draggable/interactive elements because when the target changes mid-flight they respond continuously from the current velocity, whereas a tween would restart. Framer Motion supports both; pick tween for deterministic UI and spring for tactile, interruptible motion.

Framer Motion — declarative animation for React. You swap an element for its motion.* counterpart (motion.div) and describe states as props: initial (start), animate (end), transition (timing/type). An entrance is just initial={{ opacity: 0, y: 20 }} -> animate={{ opacity: 1, y: 0 }}. Its x/y/scale/rotate shorthands map to transform, so it stays on the cheap composite path by design. variants let you name reusable state sets and orchestrate children with staggerChildren. It's the declarative, state-driven way to do what you'd otherwise wire up imperatively.

Exit animations — the thing React can't do alone. React removes a component from the DOM the instant it unmounts, so there's no chance to animate it out. Wrapping elements in <AnimatePresence> defers the actual unmount until the element's exit animation finishes — enabling leave animations for list removals and route changes. It's exactly like a graceful-shutdown drain: instead of instantly killing the component, you let in-flight work (the animation) complete first.

Layout animations and FLIP. The layout prop makes an element smoothly animate to its new position/size when the layout changes (a list reorders, a card expands). Under the hood it uses FLIP — First, Last, Invert, Play: measure the start and end box, apply an inverse transform so the element looks unmoved, then animate that transform to zero. Because FLIP animates transform (not width/top), the reorder stays on the compositor and smooth. This is how you animate layout changes without paying the reflow-every-frame cost.

Page transitions. Combine the two: wrap routed content in <AnimatePresence mode="wait"> so the outgoing page finishes its exit before the incoming one enters, and key a motion.div by the current path so Framer Motion treats each route as a distinct element to animate in and out. Give it initial/animate/exit (often a simple opacity or slide) and a short transition.

Accessibility — honor prefers-reduced-motion. Vestibular disorders make large motion literally nauseating, so the OS exposes a "reduce motion" setting. Respect it: in CSS, wrap non-essential animation in @media (prefers-reduced-motion: reduce) and disable or shorten it; in Framer Motion, use the useReducedMotion() hook to swap big movement for a simple fade or none. Don't remove all feedback — keep subtle opacity changes — just kill the large parallax, spins, and slides. This is a real accessibility requirement, not a nicety.

Practical guardrails. Prefer CSS transitions/keyframes for simple, self-contained micro-interactions (they need no JS and stay on the compositor) and reach for Framer Motion when you need exit animations, layout/FLIP, orchestration, or gesture-driven springs. Keep animations short (150–350ms for UI) — long animations feel sluggish. Avoid animating many elements at once, use will-change sparingly (it promotes a layer but overuse wastes memory), and always test on a mid-range device, not just your fast laptop.

The mental model (memorise this). Animate transform and opacity only — they ride the GPU compositor and skip layout/paint, so they hold 60fps; geometry properties force reflow every frame and jank. CSS transitions animate a state change and keyframes animate a looping timeline; tweens use a fixed-duration easing curve while springs use interruptible physics. Framer Motion adds what React can't: AnimatePresence for exit animations (a graceful drain before unmount) and layout/FLIP for smooth reorders — and always honor prefers-reduced-motion.