A UI animation can be driven three ways: a CSS transition or keyframe animation, the Web Animations API through Element.animate(), or a requestAnimationFrame loop that writes styles every frame. How do you choose between them?

## Three drivers, one ordering principle All three produce motion. They differ in *who computes the value on each frame*, and that is the whole decision: - **CSS transition / `@keyframes`** — you declare the start and end states; the browser interpolates. - **Web Animations API (`Element.animate()`)** — you hand the browser the same kind of keyframe list from JavaScript and get an `Animation` object back; the browser still interpolates. - **`requestAnimationFrame` loop** — your code computes a value every frame and writes it to the DOM itself. The cheapest option is the one that puts the least JavaScript in the per-frame path. Start at the top of that list and move down only when something forces you to. ## CSS transitions and keyframes: the default Most product motion is state-driven: a menu opens, a button hovers, a toast enters, a chevron rotates. The start and end values are known when you write the CSS, so a transition expresses it exactly: ```css .toast { opacity: 0; transform: translateY(8px); transition: opacity 180ms ease-out, transform 180ms ease-out; } .toast[data-visible] { opacity: 1; transform: none; } ``` What you get: no per-frame JavaScript, timing owned by the browser, easing and delays declared in one place, and — importantly for robustness — an animation that can continue even while the main thread is occupied with something else. What you give up: the values must be static, sequencing beyond `transition-delay` is awkward, and control after it starts is limited to changing classes. Use `@keyframes` instead of a transition when the motion has intermediate steps, needs to loop, or must run without a state change (a pulsing indicator). ## The Web Animations API: same engine, a handle `Element.animate()` takes the same conceptual input — a keyframe list plus timing options — and returns an `Animation`: ```js const animation = el.animate( [{ transform: 'translateX(0)' }, { transform: `translateX(${distance}px)` }], { duration: 320, easing: 'cubic-bezier(0.2, 0, 0, 1)', fill: 'both' } ); await animation.finished; ``` Reach for it when at least one of these is true: 1. **The values are only known at runtime.** A distance measured from the DOM, a colour from a theme object, a duration proportional to how far something travels. Writing those into CSS means injecting style strings or custom properties from JavaScript anyway. 2. **You need playback control.** `pause()`, `play()`, `reverse()`, `cancel()`, `finish()`, `playbackRate` for slowing or speeding a running animation, and `currentTime` for seeking to a position — for scrubbing, for interruption, for debugging. 3. **You need to sequence or clean up.** `animation.finished` is a promise, which composes with `async/await` far better than a `transitionend` listener that you must remember to remove and that fires per property. `document.getAnimations()` and `element.getAnimations()` let you find everything in flight and cancel it — invaluable when a user interrupts a transition halfway. 4. **The element is created and animated in the same breath**, where adding a class and waiting a frame for the transition to register is the fiddly alternative. Because WAAPI feeds the same animation engine as CSS, choosing it does not by itself make the animation more expensive than the CSS equivalent. ## The requestAnimationFrame loop: last resort, and sometimes the only option A per-frame loop is right when the value on each frame is not an interpolation between two known states: - **Physics** — springs, inertia, momentum scrolling, anything whose next value depends on velocity rather than elapsed fraction. - **Live input** — a value tracking pointer position, device orientation, audio amplitude, or streaming data. - **Drawing** — `<canvas>` and WebGL, where there is no element whose style you could transition in the first place. The cost is unavoidable: your code runs on the main thread every frame, inside the frame budget, and the animation stops dead if anything else occupies that thread. That is why a rAF-driven animation and a declarative one can behave completely differently under load even when they look identical when the page is idle. ## Two modern refinements Scroll-linked effects used to be the classic reason to write a rAF loop. CSS scroll-driven animations (`animation-timeline: scroll()` and `view()`) express many of them declaratively instead; support is still uneven across browsers, so check before relying on it rather than assuming. Separately, for cross-element transitions where whole sections of the page change at once, the View Transition API can replace hand-written choreography — again, verify support for your target browsers. ## Answering it well Do not present this as a ranking of "CSS is fast, JavaScript is slow". Present it as: how much of this animation must my code compute, and what control do I need over it once it starts? Declarative when the answer is "nothing and none"; WAAPI when you need the handle; a per-frame loop when the value genuinely cannot be interpolated.