Every animated component library is selling the same thing: a landing page that looks like effort was spent on it. The question nobody asks before installing is what the effect costs, and the answer is rarely the component. It is the runtime that arrives with it, and the fact that most of these effects have a CSS equivalent that ships nothing.
The three tiers of cost
Free. CSS transitions, keyframes, transforms and prefers-reduced-motion. A shimmer, a marquee, a hover lift, a gradient sweep, a reveal on scroll with CSS scroll-driven animations. No bytes beyond the rule itself, and it runs off the main thread.
Cheap. One small library doing one thing. A 5KB WebGL globe, a scroll observer, a tiny spring. You are paying for something specific.
Expensive. A general animation runtime, or a 3D engine. Justified when the product's whole surface is animated. Hard to justify for a hero, a headline and a button, which is what most landing pages actually need.
The useful discipline is to notice which tier you are buying into, because installing one component from a library commits you to its runtime for the rest of the page whether you use it again or not.
What the registries are for
The animated registries are worth using. What they are worth is the composition: someone has already decided the timing, the easing and the layering, which is the part that takes longest and the part a CSS rewrite loses.
Magic UI is the largest, Aceternity the most recognisable, Kokonut the cleanest, Cult UI the most interaction-led, and Motion Primitives the most building-block shaped.
The practical approach: take one or two finished pieces where the composition matters, and write the small stuff yourself.
What is genuinely CSS now
Worth knowing, because a lot of advice predates it.
Scroll reveals and progress bars: animation-timeline: view() and scroll() do this natively, off the main thread. A marquee: two duplicated tracks and a keyframe. A shimmer: a moving gradient with background-clip. A hover tilt: perspective plus rotate3d. Height to auto: grid-template-rows from 0fr to 1fr, or interpolate-size: allow-keywords. A spring: linear() easing.
What still needs JavaScript: gestures and drag, physics that respond to input, layout animations where an element moves between two positions in different containers, and orchestration across many elements with interruption.
The three checks before shipping any of it
Reduced motion. Every effect in every one of these libraries is motion. @media (prefers-reduced-motion: reduce) needs a real branch that renders the end state, not a shorter duration.
The main thread. Animate transform and opacity, which the compositor handles. Animating top, height, box-shadow or background-position puts work on the main thread on every frame, and on a phone that is where the jank comes from.
What it is hiding. An animation that reveals text means the text was not there. For a headline that is the most expensive possible mistake, because it is the string search engines and answer engines read first.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| CSS | Most of it, honestly, and increasingly all of it | Orchestration and gestures get verbose |
| Motion | Gestures, layout animations, interruptible sequences | A runtime, and easy to install for one effect |
| GSAP | Timelines, pinning, scrubbed sequences | The heaviest, and pinning is easy to overuse |
| The animated registries | Finished compositions with the timing already decided | Their runtime comes with them |
| 21st | The same components with previews, across every registry | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for an effect, get the previews inline, and let the agent write the file.
Frequently asked
- Do I need an animation library?
- Less often than the ecosystem suggests. CSS now covers scroll reveals and progress with animation-timeline, marquees with duplicated tracks, shimmers with a moving gradient, hover tilts with perspective, height-to-auto with grid-template-rows, and springs with linear() easing. JavaScript is still needed for gestures, physics that respond to input, layout animations across containers, and interruptible orchestration.
- What do animated component libraries actually give you?
- The composition. Someone has already decided the timing, easing and layering, which is the part that takes longest and the part a hand-written CSS rewrite loses. The practical approach is to take one or two finished pieces where the composition matters and write the small effects yourself.
- What should I check before shipping an animation?
- Three things. A real prefers-reduced-motion branch that renders the end state rather than a shorter duration. Whether the property being animated is transform or opacity, which the compositor handles, rather than top, height or box-shadow, which land on the main thread. And whether the animation is hiding text that should have been in the HTML.
- Is it bad to install a library for one effect?
- It is a bigger commitment than it looks, because the runtime is now on the page whether or not you use it again. That is the argument for noticing which cost tier you are buying into: free CSS, one small single-purpose library, or a general runtime worth it only when the whole surface is animated.