Not every animation needs JavaScript. And not every animation can survive without it. The choice between CSS and JS animation isn't about which is “better” — it's about matching the tool to the job.

If you've ever dropped a GSAP import for a hover effect that a transition could handle, you've over-engineered. If you've ever tried to orchestrate a 12-step scroll-driven sequence with pure CSS and lost your mind, you've under-tooled. Both hurt. Here's how to stop doing both.

The real difference

CSS animations run on the browser's compositor thread. That's the thread that handles painting pixels to screen separate from the main thread where your JavaScript executes, your DOM updates, your event handlers fire. When a CSS animation only touches transform and opacity, the browser can run it without ever touching the main thread. Zero jank. Buttery 60fps. Even when your JS is busy doing something heavy.

JavaScript animations, by default, run on the main thread. Every frame, your code executes, calculates the next value, applies it to the DOM. If anything else on the main thread is busy — a large DOM recalculation, a fetch callback, a heavy loop — your animation stutters. That's the fundamental tradeoff.

But here's the thing: JS gives you control. Pause, reverse, seek, sync to scroll position, respond to user input mid-animation, chain complex sequences with conditional logic. CSS gives you none of that. It gives you declare-and-forget. Which is sometimes exactly what you want.

A side-by-side comparison

• Performance — CSS: compositor-optimised for transform/opacity. JavaScript: main-thread bound (unless using WAAPI).
• Control — CSS: limited, no pause, seek, or dynamic values. JavaScript: full — pause, reverse, seek, callbacks.
• Scroll sync — CSS: possible via scroll-timeline (limited). JavaScript: ScrollTrigger, IntersectionObserver.
• Complexity — CSS: great for single-property transitions. JavaScript: required for orchestrated sequences.
• Dependencies — CSS: zero. JavaScript: often requires GSAP, Framer Motion, etc.
• Debugging — CSS: Chrome animation inspector. JavaScript: console, breakpoints, GSAP DevTools.

When CSS is the right call

Use CSS when the animation is decorative, simple, and stateless. Hover effects. Loading spinners. Fade-ins on page load. Button micro-interactions. Anything where you define a start state and an end state and let the browser interpolate.

A card hover effect is the canonical example. Two lines of CSS: a transition on transform and box-shadow, plus a :hover rule. No library. No runtime cost. No bundle impact. The browser handles every frame on the compositor thread.

If you're importing GSAP to do this, stop. You're adding 30kb+ to your bundle for something the browser does natively, on a separate thread, for free.

Rule of thumb: If the animation has two states (A → B) and is triggered by a pseudo-class or class toggle, CSS is almost always the right choice.

When JavaScript is the right call

Use JS when you need orchestration, reactivity, or scroll-driven sequencing. When you have a timeline with 8 elements that need to stagger in, pause at a certain scroll position, and reverse on scroll-up — CSS cannot do this. Not cleanly. Not maintainably.

This is where GSAP, Framer Motion, Motion One, and the Web Animations API earn their keep. They're not replacements for CSS — they're tools for problems CSS was never designed to solve.

JS is also the right call when:

• You need physics-based motion (spring, inertia, drag).
• You need to animate values that aren't CSS properties — like an SVG path's d attribute, a canvas draw call, or a WebGL uniform.
• You need to coordinate animation with application state — a modal that waits for data before transitioning in, a chart that animates to new values when the dataset changes.
• You need to interrupt and redirect mid-animation based on user input.

The hybrid approach

The best production codebases use both. CSS handles the 80% — the hover states, the transitions, the simple reveals. JS handles the 20% that actually needs orchestration. The mistake is reaching for JS for everything, or trying to force CSS to do things it can't.

Use CSS for:

• Hover, focus, and active states
• Simple opacity and transform transitions
• Loading spinners and looping decorations
• Class-toggle animations (open/close, show/hide)
• Anything that should work without JavaScript enabled

Use JS for:

• Scroll-driven sequences and parallax
• Multi-step orchestrated timelines
• Physics-based and spring animations
• Animations synced to data or application state
• Anything you need to pause, seek, or reverse programmatically

Performance isn't everything

Yes, CSS animations can be compositor-optimised. Yes, that's a real performance advantage. But in practice, most JS animation performance issues come from animating the wrong properties — width, height, top, left — not from using JS itself. A well-written GSAP animation that only touches transform and opacity will run at 60fps on any modern device.

The real cost of JS animation isn't performance. It's dependency weight and complexity. GSAP is ~30kb gzipped. Framer Motion is bigger. If your entire animation layer is 6 hover effects and a fade-in, that's 30kb you didn't need to ship.

The question isn't CSS or JS. It's: does this animation need runtime control? If yes → JS. If no → CSS. That's it. That's the whole framework for deciding.

What about the Web Animations API?

WAAPI is the browser-native middle ground. It gives you JS-level control (play, pause, reverse, finish callbacks) while still running on the compositor for transform/opacity. It's the best of both worlds — in theory. In practice, it lacks GSAP's timeline orchestration, ScrollTrigger integration, and the massive ecosystem of plugins. It's good for simple programmatic animations. It's not yet a full replacement for GSAP in complex production work.

Watch this space, though. As browser support matures and scroll-timeline becomes standard, the gap will narrow. The future probably looks like WAAPI + CSS scroll-driven animations handling 90% of use cases, with GSAP reserved for the truly complex 10%.

Don't import a library for a hover effect. Don't write a 40-line @keyframes rule for a scroll-driven timeline. Match the tool to the complexity of the motion. CSS for the simple and stateless. JS for the orchestrated and interactive. Both, together, for everything in between.