the score.

One playhead, three lanes.

What you see above is one timeline. It does not run by accident — every motion has a start time, a duration, and an easing curve. GSAP is, in essence, a long-running argument that animation is composed the way music is composed: as a score where many parts share one clock. Drag the playhead, and watch the parts behave.

Lane I — chord. Three bars enter from the left in sequence, each starting before the previous one has finished. The visual rhyme is deliberate: a chord is what arrives when notes overlap. The bars are aligned in time the way a chord is aligned in pitch.

Lane II — turn. A single square rotates almost a full revolution, then settles. The motion uses an ease — power3.inOut — so it begins slowly, accelerates through the middle, and decelerates at the end. Linear motion is the rare exception in GSAP; everything else has weight.

Lane III — stagger. Twenty-four dots arrive over four beats, each delayed slightly behind its neighbour. Stagger is GSAP's most-quoted trick. It is also the one that survives the longest in production sites — repeating a small motion, with a small offset, builds rhythm out of nothing.

Animation is composed the way music is composed.

The library is older than it looks.

GreenSock — the company — has been writing tweening engines since 2008, when the web's animation surface was still Flash. The library you are running predates Web Animations API, predates CSS transitions, and predates the four browser engines that have come and gone since it shipped. The continuity is the product. Every property the DOM exposes, every transform matrix, every CSS variable — GSAP has a tested path through it, and a way to put that path on a timeline alongside the others.

What changed in 2020 was free distribution: GSAP went from per-seat license to MIT for non-commercial work, with a single donation wall in front of a few specialised plugins. Since then it has quietly become the library that powers the marquee animation work on the modern web — the agency reels, the product launches, the scroll-driven editorial sites. None of that work credits a tweening engine. None of it would exist without one.

What a timeline is, in code.

The timeline above is, literally, this:

const tl = gsap.timeline({ paused: true });

tl.from('.bar-1', { x: -560, opacity: 0 }, 0.0)
  .from('.bar-2', { x: -560, opacity: 0 }, 0.18)
  .from('.bar-3', { x: -560, opacity: 0 }, 0.36)
  .addLabel('chord', 1.2)
  .to('#rotor', { rotation: 340, duration: 1.4,
                  ease: 'power3.inOut' }, 1.2)
  .addLabel('turn', 2.6)
  .from('.dot', { y: 24, opacity: 0, scale: 0,
                  stagger: 0.04, ease: 'back.out(1.7)' }, 2.6)
  .addLabel('rest', 3.7);

A line a tween. A label a moment. A timeline a list. The HUD above the stage shows the same numbers — duration, current time, currently-passing label, normalised progress — that GSAP is using internally, refreshed every frame. The library has nothing else, and it does not need anything else.

A timeline is a list.