Some frontend problems look like component problems until you try to ship them.
A scroll sequence might involve a few pieces of content, an image, some transitions and a pinned section. On the surface, each part can be componentised. But the behaviour itself depends on all of them moving together, along with the viewport, scroll position and the page around them.
That is where the usual component boundary starts to become less useful.
UI libraries are excellent at giving us interface primitives, while tools such as GSAP and Motion give us the mechanics for animation. But there is still another layer to think about: how several parts of a page coordinate to create one interaction.
That is the distinction I find more useful when thinking about creative frontend work.
The useful boundary is not always the component
Component boundaries work well when behaviour can be contained. A dropdown can manage whether it is open, a dialog can manage focus and escape behaviour, and a button can own its hover or pressed states.
The model gets harder when an interaction depends on things outside a single component: scroll position, viewport size, surrounding content, shared timing, route lifecycle or pointer behaviour.
At that point, breaking the implementation into components does not necessarily tell you where the interaction itself begins and ends.
The behaviour might span five components while still functioning as one system.
Consider a pinned scroll section
Imagine a section that enters the viewport and stays pinned while the user scrolls through three pieces of content. As each one becomes active, the visual beside it changes, and once the sequence is complete, the page returns to its normal flow.
GSAP and ScrollTrigger can handle that implementation very well. The more difficult questions, however, appear before the timeline is written.
How long should the section stay pinned? Should the visual respond continuously to scroll or change at defined points? Should the copy and visual move together, or should one remain stable while the other progresses?
Those decisions become more important once the interaction leaves the desktop mockup.
On a narrow screen, keeping the same pinned behaviour may consume too much of the viewport and make the experience feel restrictive. It may make more sense to keep the content in normal document flow and simplify the transitions instead of scaling down the desktop treatment.
Reduced motion introduces another version of the same problem. The information hierarchy should remain understandable even if the larger transforms or scroll-linked movement are removed.
Then there are ordinary production concerns. Content changes can affect measurements, responsive layouts can alter timing assumptions, and timelines or observers need to be cleaned up when a page or route disappears.
Choosing an animation library does not answer those questions. It gives you the machinery to implement the decisions after you have made them.
That difference matters.
Sometimes the reusable unit is the behaviour
This changes how I think about reuse.
For some interactions, the useful reusable unit is not a single component. It is the behaviour together with the assumptions required to make that behaviour work across different conditions.
That might include its desktop treatment, mobile alternative, reduced-motion behaviour, lifecycle handling and the places where a developer is expected to change the implementation.
This is also the territory where Vault fits.
It is not trying to provide another button, dialog or card system. Those problems already have strong solutions. Vault is focused more on interaction patterns such as scroll behaviour, transitions, cursors, text treatments, backgrounds and WebGL experiences where coordination often matters more than the individual element.
The implementation underneath those interactions can vary. Some need CSS, others make more sense with Motion or GSAP, and more visual experiences may require Three.js or WebGL.
The technology is a means of implementing the interaction. It should not become the idea itself.
Why source ownership matters here
There is another decision that becomes important once an interaction is expected to change significantly from one project to another: how much abstraction should sit between the developer and the implementation?
Vault takes a source-first approach, so the interaction code becomes part of the project and can be edited directly. That makes it possible to change timing, layout assumptions, responsive behaviour, triggers or choreography according to the needs of the page.
There is a trade-off, though.
Once your team changes that source, it also owns those changes. A heavily customised version can diverge from its original implementation, maintenance becomes your responsibility, and future updates may require judgement rather than simply increasing a package version.
That is not necessarily a disadvantage. It is an ownership decision.
A sealed abstraction can be useful for highly standardised primitives because consistency matters more than individual expression. An interaction whose value depends on fitting the composition around it often benefits from having more room to change.
The right model depends on what you are actually trying to reuse.
A useful way to decide
Before deciding whether something should become another component or immediately choosing an animation library, I find it useful to look at the boundaries of the behaviour first.
Does the interaction belong to one element, or does it coordinate several parts of the page? Does it depend on scroll state, viewport size, shared timing or route lifecycle? Would the core interaction still make sense if the animation library changed?
It is also worth asking what happens when the environment changes. A useful interaction should have an answer for smaller screens, reduced motion, changing content dimensions and the point where the page is no longer mounted.
Those questions reveal the actual unit you are designing.
Sometimes that unit is a component. Sometimes it is a larger behaviour that several components participate in.
That is the space I find most interesting about interaction systems: they sit between interface primitives and animation machinery without trying to replace either.
When several pieces of the page have to behave as one, it makes sense to define that interaction first and choose the machinery second.
Top comments (0)