How We Use GSAP to Bring Our Projects to Life

CSS transitions handle hover states and simple fades just fine, but the moment an animation needs to be sequenced, interrupted, or made to behave differently depending on the viewport, they run out of road. GSAP gives us a single timeline API that works the same way across every browser we ship to, plus gsap.matchMedia() to branch behavior cleanly — the same menu that opens as a full-screen reveal on desktop collapses to something calmer on mobile, and every animation on the site steps aside entirely when a visitor has reduced motion turned on.

Most of what visitors notice is ScrollTrigger, paired with Lenis for smooth scrolling — text and sections that reveal as they enter the viewport, timed to feel inevitable rather than triggered. SplitText breaks headlines into words so they can animate in individually instead of appearing as a flat block. On more interactive builds we reach for Flip and Observer — the same pair driving this blog's own gallery — to make layout changes and swipe-driven navigation feel physical instead of instant. Page transitions get the same treatment: a full-screen effect covers the old page, the new one loads underneath, and the cover lifts away, so a route change feels like one continuous motion instead of a hard cut.

None of it is there to show off. Every animation is judged on whether it makes an interface easier to read or a transition easier to follow — if it doesn't, it gets cut, no matter how good it looked in isolation. That restraint is what clients actually notice, even if they couldn't name GSAP if you asked them: a site that feels considered, responds the moment you interact with it, and never gets in the way of the content it's supposed to be presenting.