I Discovered GSAP and Wanted to Animate Everything

I Was Already Using GSAP Without Really Discovering It

The portfolio already had GSAP Core and timelines. In Approach, ScrollTrigger supported a mechanical narrative tied to scrolling; in Work, Flip made it possible for Projects and Services to change configuration without breaking continuity; and Home had an entry sequence to introduce the visual identity. Those were real uses, designed around specific problems.

My relationship with the library was still more practical than deep. I could decide whether an experience looked right, but I did not have a clear mental map of how its pieces connected or how many possibilities sat behind them.

AI helped with research, suggesting alternatives, explaining decisions, reviewing implementations, and finding problems. I could approve or reject a visual result, but that did not always mean I could explain every technical detail. Starting to experiment manually became a way to close that gap: change a property, see what moved, and stop treating the result like a black box.

Then I Found SplitText

The first conscious experiment was small and independent, inside gsap-lab/. The text was simple: Engineering and web development. I wanted to split it into words and characters, then see what changed when I varied only a few properties: y, duration, stagger, and ease.

const split = SplitText.create(target, {
  type: "words,chars"
});

Producing a spectacular animation was not the important part. To understand what each value controlled, I exaggerated them first: I pushed y much further, made the stagger far too slow, and compared back.out() with power3.out. That made the effect of each parameter easier to see.

Then I could bring the values back down and start deciding the rhythm instead of copying a configuration that only looked pretty. That small exercise started turning GSAP from “magic someone else wrote” into a tool I could observe and understand. Not because I suddenly knew it deeply, but because I was beginning to recognize the relationship between a decision and its consequence.

Naturally, I Wanted to Use Everything

After SplitText, I made the most predictable mistake possible: I kept reading. Then came ScrambleText, DrawSVG, MotionPath, masks, stagger, and a long list of examples that all seemed to have a possible place in the portfolio.

I started imagining text resolving like a signal, lines drawing themselves, points travelling across connections, and every heading getting its own entrance. My first reaction was basically: I want all of it. It was easy to justify anything: if a plugin existed, surely there was a section where it could look good. That was not a reasonable conclusion, but it was an honest reaction to discovering a new vocabulary.

The problem was not intensity. It was dispersion. If every element receives a different animation just because it can, the interface stops having rhythm and starts asking for attention from every direction.

The Risk of Turning a Portfolio Into a Fairground

The first answer could have been “use fewer animations.” But that did not describe what I wanted to build either. Home could be deliberately cinematic; Approach could tell a mechanical story; Work could feel physical when it changed state. The problem was not that some surfaces had personality.

The conclusion was different: Do not limit the intensity. Limit where it spreads. Each page could play a different role in the whole and therefore move in a different way. Engineering Notes and Contact did not need to compete with those experiences; they could remain quieter spaces for reading or starting a conversation.

That also made it easier to discard ideas. An animation can be attractive and still have no job inside the interface. When it does not explain hierarchy, change, connection, or response, it is probably taking up more mental space than it gives back.

From Effects to a Motion Vocabulary

To avoid deciding every animation from scratch, I ended up organizing the plugins into a vocabulary for this portfolio. It is not a universal method or a rule for other sites; it is a way to remember what each resource is supposed to do before I use it.

REVEAL         → SplitText
INITIALIZATION → ScrambleText
CONNECTION     → DrawSVG
DATA MOVEMENT  → MotionPath
STATE CHANGE   → Flip
SCROLL STORY   → ScrollTrigger

SplitText reveals an identity that already exists in the HTML. ScrambleText makes sense when a label resolves from an initial reading into its real text. DrawSVG lets a connection appear as a connection instead of a simple opacity change. MotionPath can let one pulse stand for data or an impulse travelling through a line. Flip preserves continuity when the interface changes state, while ScrollTrigger ties a story to reading.

Naming those relationships did not make them more important than they are. It kept me from using them interchangeably. If motion has a verb, it is easier to ask whether that verb matches what the interface needs to say.

Home Stopped Loading and Started Assembling

That vocabulary settled into the Cinematic System Boot on Home. The sentence guiding the decision was simple: Home does not load; Home assembles. I did not want a waiting screen or pretend telemetry. I wanted the interface that already exists to build itself in front of the visitor.

The final sequence works like this: instrumentation appears through DrawSVG; a short pulse travels along a path with MotionPath; the eyebrow resolves through ScrambleText; the name appears with SplitText; the photograph enters as the core; the technologies find their position around it; and finally the text, CTAs, and channels arrive.

A first visit in a session can show that complete version. Returning to Home in the same session uses a shorter version instead of replaying the entire film. I like that decision because it gives the experience presence without punishing repeated navigation. After the boot, the orbit remains the only piece in continuous motion.

I Also Learned When Not to Animate

Discovering more plugins did not mean spreading them across the entire site. Work did not receive TextPlugin just because it existed. Engineering Notes did not need GSAP to carry a long entry. Contact did not need another experience on top of a surface that should already be direct. The Hero did not end up with a typewriter, and random particles stayed out.

Some of those decisions became easier after trying possibilities. Learning a tool also means deciding when not to use it. Sometimes the most useful answer is not to add motion, but to let one part of an interface stay quiet so another can carry weight.

What I Still Don't Know

Using several GSAP plugins does not mean I master GSAP. I am still learning about complex timelines, easings, composition, SVG, performance, motion accessibility, and how plugins interact with one another. I am also still figuring out which decisions feel right for a concrete reason and which only seem interesting for the first few seconds.

I wanted to leave this note so I can come back later and see how much my understanding changed. Maybe some things that feel difficult now will be ordinary later; maybe I will find I was making other things more complicated than they needed to be. I would rather compare that with something written than trust myself to remember how I thought.

What Really Blew My Mind

The surprising part was not discovering that letters can move or lines can be drawn. It was understanding that animation can explain an appearance, a connection, a flow, a transformation, a hierarchy, or a state. It can help an interface do more than show information: it can make a relationship between its parts visible.

That is where motion stops being an isolated effect and starts becoming part of an interface language. Every animation should be able to answer two questions: What is it doing? and Why does it need to move? If there is no clear answer, it is probably just an effect. And yes, I still want to play with a lot of them.