IX3 or GSAP? Where I draw the line
Webflow Interactions now run on GSAP, so the real question is who edits the site next. That person decides where the motion lives: in the panel or in the code.
Since Webflow rebuilt Interactions on top of GSAP, the question I hear most from the teams I hand sites to has changed. It used to be "can Webflow do this?" Now it's "should this be an interaction or code?" My answer has settled into a simple rule: the person who edits the site next decides.
Who touches it next
A marketing team will change a headline on a Tuesday afternoon without telling anyone. If the reveal on that headline lives in the Interactions panel, it keeps working, and if they want it slower, they can drag a number. If it lives in a script, the new headline arrives without its animation and nobody knows why. So my first question about any piece of motion isn't technical at all. It's whether a non-developer might reasonably want to change it.
The second question is whether the motion depends on anything the page has to calculate. A fade doesn't care how long the headline is. A marquee does, and so does anything that follows the pointer or reacts to a value. Those are the cases where an editable panel stops being a help and starts hiding logic in places nobody will think to look.
What I build with Interactions
- Scroll reveals and staggered lists
- Hover states that move more than one element, like an image zoom with a label sliding in
- Page-load sequences, including split-text headings
- Scroll-scrubbed parallax on a single image or section
These are the things a team asks to tweak. They're visible in the Designer, they're named in plain language, and they respect reduced motion with one setting.
What stays in code
Anything with state, measurement or logic. A marquee that measures its own content before it loops. A theme toggle that tweens every colour variable between light and dark. A pointer that follows the cursor. A small game. When I built the macOS-style portfolio, every window, the dock and the memory game ran on GSAP in code, because the behaviour was the product.
Interactions are content. If a client would ask me to change it, it belongs somewhere they can reach.
One script, guarded
When code is the right call, I keep it in a single site-wide script, and every feature checks for its own elements first. On a page without a marquee, the marquee code quietly does nothing. That keeps the handover short: one place to look, and nothing that breaks when a page is duplicated.
The line moves a little with every project, and that's fine. What doesn't move is the question underneath it.
