A button changes color on hover. A card expands into a modal. A product story pins sections while images move through a sequence. A liquid surface reacts to the pointer.
Calling all four of these things “website animation” hides the decision that actually matters.
CSS, GSAP, Motion and Three.js can all participate in a website's motion system, but they operate at different layers. CSS is excellent when animation belongs to styling and interface state. Motion fits naturally when movement follows React state, layout or gestures. GSAP becomes attractive when timing and orchestration are the difficult parts. Three.js belongs to a different rendering model entirely: scenes, cameras, meshes, materials and shaders rather than ordinary DOM elements.
| Choose | When the problem is mainly | |---|---| | CSS | States, hover/focus feedback, simple entrances and self-contained transitions | | Motion | React state, component enter/exit, layout changes, gestures and UI-oriented motion | | GSAP | Precise sequences, scroll choreography, timelines, SVG or imperative multi-element animation | | Three.js | WebGL scenes, shaders, particles, 3D objects and graphics that should not be DOM elements |
A well-built marketing page might use all four. Its buttons could use CSS, its mobile navigation could use Motion, its scroll narrative could use GSAP and its hero canvas could use Three.js.
The architecture should follow the interaction rather than forcing every effect through whichever package happens to be installed already.
Suppose a button needs to move upward by two pixels and change background color on hover.
Installing an animation library for that interaction does not make it more sophisticated. It gives a small state transition another runtime abstraction.
CSS transitions are especially good when animation is a direct consequence of CSS state: :hover :focus-visible :active a class changing a data attribute changing a media query changing
Keyframe animations extend that model when the movement has intermediate states rather than a simple start and end.
Browsers already have substantial machinery for running these animations. The cost depends heavily on which properties are changing, not simply whether CSS or JavaScript initiated them.
“CSS is fast, JavaScript is slow” is too crude to be useful. Animating transform and opacity is very different from repeatedly forcing layout and paint work. A badly chosen CSS property can still produce a bad animation.
CSS scroll-driven animations can tie keyframe progress directly to a scroll or view timeline. The View Transitions API handles another class of state and page transitions natively, while the Web Animations API gives JavaScript direct control over browser animations without requiring a full animation library.
These APIs do not make Motion or GSAP obsolete. They move the point at which a dependency becomes justified.
A progress indicator linked directly to document scroll may no longer require scroll-event code. A tightly choreographed pinned product sequence with overlapping states still has a very different coordination problem.
Imagine a hero sequence with six elements: the eyebrow appears; the heading reveals; two decorative lines extend; the image begins moving before the heading finishes; metadata follows 120ms later; everything reverses differently when the section leaves.
Change the duration of the heading and you may need to recalculate several delays. Add another step and the sequence becomes a small scheduling system expressed through stylesheets.
Once the timing relationships become harder to maintain than the transforms themselves, a timeline starts earning its place.