I work on Vault at Hyperiux, an interaction library for React and Next.js. Most people first encounter it through the visual side of the product: a cursor effect, a text interaction, a transition, a scroll treatment, or something running in WebGL.
That is also the easiest part to notice.
The harder part begins when an interaction leaves the demo and has to live inside a real website. Typography changes, content becomes unpredictable, the viewport gets smaller, several animations start running at once, and accessibility or performance constraints enter the implementation.
A good interaction has to survive that transition.
The problem is rarely finding inspiration
Frontend developers are not short on references. There is no shortage of websites, experiments, videos, CodePens, and saved posts showing interesting things the browser can do.
The gap appears between seeing an interaction and getting it into a project in a form you can actually maintain.
You may understand the visual idea immediately, but reproducing it means working through timing, DOM structure, responsive behaviour, dependencies, cleanup, reduced-motion handling, and whatever assumptions the original implementation made. A small visual detail can become a fairly large implementation task once it meets the rest of the application.
That gap is where we want Vault to be useful.
Why source-first matters to us
One of the deliberate product decisions behind Vault is that the source should remain with the developer.
We could hide more behind abstractions and expose a larger configuration surface, but that creates a different problem. The further an interaction moves from its default form, the more likely the abstraction becomes something the developer has to work around.
Vault takes the opposite approach. You can start from an implementation that already has a point of view, then inspect it, change it, remove parts of it, or adapt it to the system you are building.
The interaction is a starting point, not a contract.
That matters because the final website should look like the product you are designing, not like the library the interaction came from.
More effects do not automatically produce better websites
Building a library like Vault creates an obvious temptation: keep adding more things that move.
Quantity is useful up to a point. It gives developers more starting points and more ways to explore an idea. But a larger catalog does not remove the need to decide whether an interaction belongs on a page in the first place.
Motion should have a job. It can reinforce hierarchy, connect states, make feedback clearer, direct attention, or contribute to the visual character of a product.
Sometimes it does none of those things particularly well, and the simpler implementation wins.
That is still a valid outcome.
We do not want Vault to become a reason to add motion everywhere. We want it to make the interaction layer easier to explore when motion has actually earned a place in the design.
The demo and the implementation have different jobs
A preview has to communicate an idea quickly. It needs enough context for someone to understand what an effect does and decide whether it is relevant.
The installed version has a different job.
It has to coexist with the project’s typography, layout, content, breakpoints, performance budget, accessibility requirements, and every other decision already made in the interface. What looks composed in isolation can behave very differently once it becomes one part of a larger page.
This is why I think editable source is important. The developer needs room to respond to those conditions rather than hoping the original demo anticipated all of them.
It usually did not. Demos are talented, but not clairvoyant.
What I think about as Vault’s Product Manager
A lot of product work on Vault is not about asking which visual effect looks the most impressive. The more useful questions are usually less glamorous.
How quickly can a developer understand what an effect is doing? What information should be visible before installation? Which defaults save time, and which ones quietly remove control? How much documentation does an effect need before the documentation becomes another thing to navigate around?
There is also a broader question underneath all of this: where should Vault stop?
A developer tool can help by making a difficult part of the workflow faster. It becomes less helpful when it starts pretending the remaining decisions no longer matter.
Our aim is to do enough of the work that you are not rebuilding the same interaction from zero, while leaving enough of the implementation exposed that you can still make the right decisions for your own project.
What we are trying to get right
The workflow we keep coming back to is simple:
Preview → Install → Tune → Ship
The interesting part is everything hidden inside “Tune.”
That is where the interaction starts responding to the actual product rather than the demo it came from. It is also where developers make the decisions that determine whether the effect feels intentional or merely added.
As we continue building Vault, that is the part of the product I am most interested in improving: not only how good an interaction looks when you first see it, but how useful it remains once you own the source and have to make it work somewhere real.
If you build with React or Next.js and spend time on the interaction layer, I would be interested in hearing how you approach that work, especially the parts that still feel unnecessarily repetitive.
Vault: vault.hyperiux.com
Top comments (3)
Building interaction libraries with a source-first approach is a smart move for maintaining consistency across complex component trees, especially when dealing with Next.js server components. It really solves the headache of syncing state between client and server boundaries. I actually ran into similar architectural friction when wiring up our Next.js and Supabase SaaS boilerplate, PubliFlow, where we had to rethink how UI interactions persist across route transitions. Have you found that this source-first model introduces any noticeable overhead during the initial hydration phase in Next.js?
Good question. The source-first model itself doesn’t add much hydration overhead that mostly depends on the interaction. We try to keep client boundaries narrow and make effects easy to lazy-load, trim, or adjust when needed.
Keeping client boundaries narrow is definitely the right strategy to prevent the JavaScript bundle from ballooning. It makes me wonder how you handle state sharing across those isolated boundaries when a single interaction requires context from multiple components. Have you found a clean pattern for cross-boundary communication without reintroducing heavy hydration costs?