The most interesting thing about motion design right now is that shadcn and Framer are describing opposite worlds — and both are correct.
On one side: "Look at macOS. Apple spent so much time designing marketing Liquid Glass. Two years in, very little of it has made it to the Mac. Menus, alerts, dialogs. They open instantly. Some of the glass. Almost none of the liquid." That's a designer pointing at the most motion-obsessed company in the industry and noting that the parts people actually work in were left deliberately still.
On the other side, Framer is shipping an agent that adds hover effects to a set of cards in seconds, and another that builds an animated 3D wireframe cube grid from a prompt. The marginal cost of adding motion has fallen to roughly nothing.
That combination — a strong case for near-stillness, and near-zero friction to ignore it — is the whole problem. Motion budgets used to be enforced by effort. Now they have to be enforced by judgment.
The sharpest version of the case isn't "animation is bad." It's that animation is a teaching tool with an expiry date. shadcn says it plainly: motion can show people how elements fit together, "like something sliding from the left instead of just appearing = 'ooh that's where that lives.' But after the user learns the UI, animations are less beneficial."
Read that twice. The animation's value decays with familiarity, and familiarity is what daily-use software is made of. A user who opens a command palette forty times before lunch has already learned where it lives. The slide is now just latency.
The animation's value decays with familiarity, and familiarity is what daily-use software is made of.
His test is almost insultingly simple: open the app you use every day and count how many things are animated. Almost none. That's not an aesthetic preference, it's an audit result.
Which is why a motion budget is a frequency table before it's anything else. The UI Craft docs put numbers on it: interactions used 100+ times a day — keyboard shortcuts, command palette — get no animation, ever. Things used tens of times a day — hover, list navigation, typing — get removed or drastically reduced, under 150ms or nothing. Occasional events like modals and drawers get standard treatment, 200 to 300ms, with a clear purpose. Rare and first-time moments can afford delight.
The distribution matters more than the durations. If most of your motion is sitting in tiers intended for onboarding, your product is over-animated, and no amount of easing polish will hide it.
Durations then come from a fixed scale, not from taste. Five tokens cover about 95% of UI: 120ms for opacity, color, hover, tooltips; 200ms for dropdowns, toggles, tabs; 280ms for modals and drawers; 400ms for page transitions and mobile sheets; 600ms reserved for onboarding choreography, used sparingly.
The discipline is in the refusals. Never 153ms. Never 200ms on one button and 220ms on another for the same state. A bespoke duration is a finding, not a flourish.
Easing is where most products quietly lose. Default to ease-out for anything entering — a fast start that settles gently, which is what arrival should feel like. Avoid ease-in for UI entirely, because a slow start delays feedback; a dropdown with ease-in at 300ms feels slower than ease-out at the same duration. And skip bounce and elastic on functional UI: the docs are blunt that it reads dated and pulls attention onto the animation rather than the result.
One place the sources disagree is instructive. The UI Craft choreography rule says exits run at about 75% of entrance duration. The 72Technologies budget argues for a 2:1 enter/exit ratio — exits roughly half of enters. Both agree on the direction and differ on the magnitude, which tells you this is judgment, not physics. Users have already processed the element; they don't need a second goodbye.
Choreography has its own arithmetic. One element leads — usually the modal panel, the page, the selected row — and everything else follows at lower amplitude with slight delay. Stagger siblings by 30 to 80ms. Uniform zero feels pasted-on; anything past 80ms per item makes a list feel slow by the sixth row, and past eight items you switch to a batch fade.
Then there's the part designers tend to hand-wave: the cost. One developer chased a janky canvas loop for hours, found the drawing took 1.4ms a frame, and discovered the real culprit was pacing frames with setTimeout instead of requestAnimationFrame, so frames landed at uneven times.
That's the lesson: your code often isn't the slow part. The pacing is. And pacing is now measured across the entire page lifecycle — Interaction to Next Paint replaced First Input Delay as a Core Web Vital, which means every janky scroll animation and heavy transition callback during an animated sequence is now a ranking input, not just a feeling.
The most honest budgets are enforced per page type. One project running fifteen thousand programmatic SEO pages capped those at three concurrent animations, nothing slower than 600ms, transform and opacity only — never width, height, top, or left, because those trigger layout — targeting CLS under 0.1 and LCP under 2.5s. The interactive pages, where the animation is the product, got up to six concurrent animations and durations up to a full second. Same design language, two speed limits.
There's a similar budget at the page level: on initial load, the sum of all visible animation durations shouldn't exceed 800ms. Enough to say the page is alive without making anyone wait for the introduction.
Reduced motion is not a footnote on any of this. The lazy implementation — set every duration to zero — technically respects the OS setting and practically makes the app feel broken, because modals appear with no indication of where they came from. The better default is to keep opacity transitions and remove transforms: a quick crossfade instead of a 40px slide. One source estimates that somewhere between 5% and 15% of users have vestibular disorders, migraine, or motion sensitivity that makes this a physical requirement rather than a courtesy.
And the cut list is remarkably consistent across every source: parallax on hero sections, letter-by-letter text reveals, mouse-follow cursors, ambient gradient loops, numbers counting up, staggered card entrances where each card delays 100ms more than the last, infinite looping animations. Each one adds zero communication value and a measurable cost.
That's the craft case in one line. Not "animate nothing," but animate almost nothing — and be able to name the job the survivors are doing: feedback, continuity, hierarchy, or personality. If a designer can't say which, the transition probably shouldn't ship.
The tools will keep making it easier to add motion. Framer's agent will keep getting faster at hover effects and animated cubes. That's fine, and it's actually clarifying: when motion costs nothing to produce, the only thing that makes it good is the budget you refuse to exceed.