Web performance
Parallax that won't trash your scroll performance
How we use useScroll and useTransform from Motion for parallax effects that stay on the GPU, with reduced-motion fallbacks built in.
The Blog
A rotating card ring with almost no JS
Web performance
Some motion belongs in CSS, not JavaScript. Our radial card carousel uses CSS custom properties for radius, count, and duration, responsive across breakpoints without rewriting animation timelines.
The approach
Design tokens as motion parameters
Not every animation needs a JavaScript library. Our radial cards block, a ring of rotating cards, uses CSS custom properties as its animation API. The variables --radius, --total, and --duration control the geometry and timing. A CSS @keyframes animation handles the rotation. The will-change: transform property hints the browser to composite on the GPU.
JavaScript's role is minimal: setting the custom property values at mount and adjusting them at breakpoints. Tablet gets a different radius and card count than desktop. But the animation itself , the continuous rotation, is pure CSS.
The choice
When CSS is enough
GSAP is powerful for complex, sequenced, interaction-driven animations, timelines with callbacks, scroll-triggered sequences, physics-based easing. A continuous rotation at a fixed speed with no user interaction is none of those things.
CSS animations run on the compositor thread. They don't compete with JavaScript execution for the main thread. They don't need cleanup on unmount. They don't add bundle weight.
The custom properties make it responsive without JavaScript animation logic. Change --radius at a breakpoint and the animation adapts. No timeline rebuild, no recalculation, no GSAP overhead for something CSS handles natively.
Use the right tool. GSAP for complex interactive motion. CSS for continuous, declarative animation. The radial carousel is firmly in CSS territory.