The React ecosystem is not short on UI libraries. If you need buttons, dialogs, cards, tabs, inputs, navigation or other interface primitives, there are already mature options for almost every kind of project.
So the obvious question is: why does Vault need to exist at all?
The clearest answer is that Vault is not trying to solve the same problem.
UI libraries help you build the individual pieces of an interface. Vault is focused on what can happen across those piecesβthe interactions, motion systems and effects that may belong to an entire section or sometimes the page itself.
That sounds like a small distinction, but it changes what you are actually building.
UI libraries give you the pieces
Most component libraries work around clearly defined units.
A dialog owns its open and closed states. A button owns its hover, focus and pressed states. A tab system coordinates a known group of elements with predictable behaviour.
That boundary is useful because the behaviour mostly belongs to the component itself.
Creative interactions often behave differently. They may depend on multiple components, the viewport, scroll position, pointer movement, route changes or the relationship between one section and the next.
In those cases, the interaction cannot always be understood by looking at one component in isolation.
Consider a section with three pieces of copy and a visual beside them. As the user scrolls, the section pins, the active piece of copy changes, the visual progresses through different states, and the section releases when the sequence finishes.
The typography, buttons or cards inside that section could all come from a UI library.
But the experience does not belong to any one of them. It belongs to the relationship between them.
That is the layer Vault is interested in.
Animation libraries solve a different part of the problem too
There is another reasonable question here.
If tools such as GSAP, Motion and Three.js already exist, why package interaction patterns at all?
Because choosing an animation library and deciding how an interaction should behave are two different decisions.
GSAP can give you excellent control over a scroll timeline. Motion can handle transitions, gestures and animation orchestration. Three.js gives you the rendering foundation for more visual WebGL experiences.
But none of those tools decides what the experience should be.
Go back to the pinned section.
The library can help you pin it, animate the visual and connect progress to scroll. It does not decide how long the section should remain pinned, which element should move first, whether the transitions should be continuous or discrete, or whether the interaction should even remain pinned on mobile.
Those are interaction decisions.
The animation library provides the mechanics after those decisions have been made.
That is why I find this three-layer model useful:
UI libraries provide the interface pieces. Animation libraries provide the mechanics. Interaction patterns define how those pieces behave together.
Vault sits in that third layer.
An interaction can be larger than the element you see moving
One thing that becomes obvious when you build these experiences for real is that the visible effect is often only a small part of the implementation.
A scroll interaction may look like an image moving across the screen, but its behaviour could depend on section height, viewport dimensions, the content around it, responsive breakpoints and how much scroll distance is available.
The same interaction also needs an answer for mobile.
A pinned experience that feels good on a large desktop display may take over too much space on a phone. The better version might remove pinning completely and let the content move naturally through the document.
Reduced motion introduces another consideration. The hierarchy and meaning of the section should still work even when large transitions or scroll-linked movement are simplified.
Then there is lifecycle behaviour. If an interaction creates observers, timelines or event listeners, those need to be cleaned up when the page or component disappears. If content dimensions change, measurements may need to be recalculated.
Those details are not the exciting part of interaction design.
They are, however, part of whether the interaction actually works outside a demo.
This is where Vault is different from a traditional UI library
Vault provides starting implementations for these kinds of interactions rather than another collection of standard interface primitives.
That can include scroll treatments, page transitions, cursor interactions, animated backgrounds, text effects, WebGL experiences and other behaviours where several elements may need to participate in the same experience.
Some of those interactions may be relatively small. Others can control the feeling of an entire section.
The important distinction is not how many pixels the effect covers. It is what owns the behaviour.
A hover effect may belong entirely to one element. A cursor treatment might depend on several areas of the page. A transition may need awareness of the route that is leaving and the one arriving.
The useful boundary changes with the interaction.
Why provide a starting implementation instead of a recipe?
Developers can build all of these interactions themselves. In many cases, they should.
If an interaction is central to a product or has very specific requirements, starting from first principles can make complete sense.
But rebuilding from zero is not automatically where the creative value lives.
Writing the initial scroll trigger, pointer listener or animation timeline is often just the beginning. The more interesting work is deciding how that interaction belongs to this particular page.
How should it respond to the surrounding layout? What should change on mobile? How much motion is enough? What should remain static? Where should the developer deliberately break away from the original implementation?
A good starting point removes some of the repetitive setup without trying to make those decisions permanent.
That is the role Vault is trying to play.
Source-first matters because interactions rarely stay untouched
This is also why editable source makes sense for this kind of product.
Interaction patterns tend to be adapted heavily. Timing changes. Layout assumptions change. Breakpoints change. The visual treatment becomes more specific to the brand or project.
If the implementation is hidden behind a rigid abstraction, that flexibility becomes harder.
With a source-first model, the code becomes part of the project and can be changed directly. That gives developers more control over how the interaction eventually behaves.
It also comes with a trade-off.
Once you change the source, you own those changes. If your implementation diverges significantly, your team is also responsible for maintaining that divergence and deciding how future changes should be handled.
That is not something I would describe as purely an advantage. It is an ownership model.
For a highly standardised primitive such as a dialog or form control, a stronger abstraction can be valuable because consistency is part of the point.
For an interaction that is expected to change substantially depending on the page around it, having the source close to the project can make more sense.
Vault does not need UI libraries to be inadequate
This is probably the most important part of the distinction.
Vault does not exist because component libraries are missing something they were supposed to solve.
They are solving a different problem.
A project can use its existing design system or UI library for buttons, forms, cards and navigation. It can use GSAP, Motion or Three.js where those tools make sense. Vault can sit beside both without trying to replace either.
The UI library owns the pieces. The animation library provides the machinery.
Vault provides a starting point for the interaction that connects them.
For me, that is the simplest way to understand why the product belongs in an ecosystem that already has so many frontend libraries.
Sometimes what you need is another component. Sometimes the thing you are actually designing is how the whole section behaves.
Top comments (0)