DEV Community: Jyoti Pathak

What an Interaction Library Should Tell You Before You Install Anything

Jyoti Pathak — Tue, 18 Aug 2026 13:40:39 +0000

A creative interaction can win you over in thirty seconds. The motion feels right, the timing is polished, and you can already imagine it improving the page you are building.

Installation is where that visual decision becomes a technical commitment.

Once the effect enters a project, you may also be accepting dependencies, input assumptions, rendering work, accessibility requirements, fallback behaviour, layout constraints, and maintenance responsibility. Some of those are trivial. Others can be enough to rule out an interaction before implementation begins.

That is why I think an interaction page needs to do more than demonstrate the strongest version of the effect. Before the install command, it should give a developer enough information to decide whether the interaction belongs in the project at all.

The important question is not only, "What does this look like?"

It is also, "What am I agreeing to if I use it?"

The information before installation has a different job

While working around Vault's effect catalogue, one part of the page structure I consider particularly important is the Overview.

The Overview should explain what the effect actually does and where that behaviour makes sense. A loader, page transition, cursor treatment, scroll sequence, navigation pattern, and WebGL hero might all be visually engaging, but they solve very different problems.

That context belongs before installation because it affects the adoption decision.

Detailed props, lifecycle notes, implementation guidance, source-level customisation, and optimisation techniques are still important, but presenting all of them before somebody has decided that the effect is relevant risks making discovery harder rather than easier.

I find it useful to separate the information into two layers.

The decision layer helps somebody answer, "Should I use this?"

The implementation layer helps them answer, "How do I make this work correctly in my project?"

The distinction sounds small, but it changes how documentation is organised. Instead of treating the install command as the beginning of the useful information, the page starts helping the developer make a technical judgement before anything enters the codebase.

A five-part pre-install check

For an interaction library, I think the information before installation can be organised around five questions.

1. What job does the interaction perform?

The first question is surprisingly easy to skip.

An effect should be understandable as more than a visual technique. What is it doing for the page?

A loader represents waiting. A page transition represents navigation between states. An accordion controls information disclosure. A cursor effect changes pointer feedback. A WebGL background may be primarily atmospheric.

That distinction matters because a technically impressive implementation can still be wrong for the page.

Numeric Tunnel, for example, makes more sense when there is a genuine wait to represent, such as an upload, asset preparation, data loading, or another operation that takes noticeable time. If the application is already usable almost immediately, introducing a large loader simply to create a moment for the animation would solve the wrong problem.

The first piece of pre-install information should therefore answer a basic product question: what role is this interaction expected to play?

2. What environment or input does it assume?

The next question concerns capability.

Some effects assume hover. Some assume a fine pointer. Some depend on scroll. Others assume that a WebGL context can run comfortably enough for the effect to justify itself.

These assumptions should be visible because they can change whether the interaction is relevant before any implementation work starts.

Vault currently has some preview experiences that tell the visitor when an effect is intended to be experienced on desktop. That is particularly useful for pointer-driven interactions where the desktop behaviour cannot simply be copied into a touch-first or coarse-pointer context.

The important distinction here is capability rather than device labels.

A touch-capable laptop can also have a trackpad or mouse. A tablet may have several input mechanisms available. Screen width alone does not tell us whether hover exists or whether the primary pointer is fine enough for the interaction.

For implementation decisions, concepts such as hover, pointer, any-hover, and any-pointer provide a more meaningful boundary than treating every "mobile" or "touch" environment as the same thing.

A good effect page does not need to teach those APIs before installation. It should, however, make the underlying assumption clear enough that a developer knows the interaction may need a different treatment in another input environment.

3. What does adoption add to the project?

Not every interaction carries the same implementation surface.

One effect might be mostly CSS and DOM behaviour. Another may depend on Motion or GSAP. A third may introduce Three.js, React Three Fiber, shaders, a canvas, and continuous rendering.

That difference matters before installation.

Vault uses effect-specific dependencies rather than requiring every project to inherit every engine represented in the catalogue. That keeps the dependency decision closer to the interaction that creates it.

From a documentation perspective, I think the same principle is useful: make the adoption cost visible where the adoption decision happens.

A developer does not necessarily need the full dependency graph before pressing install, but they should know when an interaction moves the project into a meaningfully heavier technical category.

Finding out after implementation that an effect requires a rendering stack the team does not want to support creates unnecessary rework.

4. What happens when the full interaction should not run?

This is where accessibility, reduced motion, mobile behaviour, and technical degradation become part of the same decision.

An interaction is much easier to adopt when the developer can understand what survives if the ideal version cannot or should not run.

For a pointer effect, the answer might be the native cursor.

For a complex animation under prefers-reduced-motion, the final readable state may appear immediately.

For a navigation interaction, keyboard accessibility and focus behaviour need to survive independently of the visual transition.

For WebGL, a static composition may preserve the art direction without requiring the renderer.

This does not mean every effect needs an elaborate fallback matrix above the install button. It means that when an interaction depends heavily on a particular capability, its fallback philosophy becomes part of its suitability.

If the only acceptable state is the full effect running exactly as shown in the preview, that is itself useful information for a production developer.

5. What could disqualify the interaction before installation?

The final question pulls the other four together.

What piece of information would make a developer decide not to use the effect?

It could be:

the interaction depends on hover, but the important audience is primarily touch-first;
the required dependency is not appropriate for the project;
meaningful content becomes inaccessible without the animation;
the fallback removes the part of the interaction that made it valuable;
the rendering cost is difficult to justify for the page;
the interaction assumes a layout or content model the project cannot guarantee.

This is where documentation can save the most wasted work.

The goal is not to make every effect look safer. It is to make it possible for the developer to reject the wrong effect early.

That is a useful outcome for a developer product.

The same framework produces very different answers

Consider two interactions that might both appear visually polished in a catalogue.

Numeric Tunnel

The page job is straightforward: it represents a wait state.

Its most important pre-install question is therefore not animation performance. It is whether the application has a wait that deserves this level of visual treatment and whether the progress being displayed corresponds to real application state.

If the operation cannot provide real percentage progress, the implementation may need an indeterminate or staged version instead. If the wait lasts only a fraction of a second, the correct decision may be not to use the loader at all.

Its adoption questions are primarily about state truthfulness, accessibility, and whether the interruption is justified.

Fractal Glass

A WebGL effect such as Fractal Glass produces a very different decision profile.

Here the developer needs to think about rendering capability, pixel density, continuous GPU work, mobile simplification, content placement, and fallback behaviour.

Device pixel ratio is not merely another configuration value. Rendering at a higher pixel density increases the number of pixels the GPU must process. A canvas rendered at twice the linear resolution contains roughly four times as many pixels. That can materially change the cost of an effect on higher-density displays.

Continuous rendering matters for a similar reason. A scene that keeps rendering while it is outside the viewport continues using resources without producing visible value.

Fractal Glass currently addresses these production concerns with measures including a DPR cap, reduced post-processing on mobile, offscreen pausing, meaningful HTML content outside the canvas, and the option of a static poster fallback.

Its pre-install questions are therefore much more about rendering cost, graceful degradation, and whether the live effect contributes enough to justify the runtime work.

The page architecture can remain consistent across Numeric Tunnel and Fractal Glass while the information inside that architecture changes substantially.

That is what standardisation should enable.

Standardisation should make differences easier to compare

Vault uses a standardised effect-page structure because consistency reduces the amount of navigation work required from the reader. Once somebody understands where the Overview, installation information, implementation guidance, performance notes, accessibility considerations, and other sections live, they can move through the catalogue more efficiently.

But standardisation should not make every effect appear equivalent.

A WebGL hero should carry different production considerations from an accordion.

A cursor interaction should surface different assumptions from a loader.

A route transition should care about different failure conditions from a background treatment.

The value of the shared structure is that those differences become easier to locate and compare.

For me, that is the more useful goal of standardised developer documentation: predictable structure, effect-specific judgement.

Where the install command should sit in the decision

I do not think the install command needs to be buried beneath a technical essay.

Creative tools should remain easy to explore. A developer who already understands the effect should be able to move quickly.

But ease of installation and quality of evaluation are not opposing goals.

Before installation, a concise page should be capable of answering:

What does this interaction do?
Where does it make sense?
What capability or environment does it assume?
What meaningful technical commitment comes with it?
What happens when the ideal interaction is unavailable or inappropriate?

Everything else can become progressively more detailed after that.

Props belong later.
Advanced tuning belongs later.
Lifecycle mechanics can belong later.
Deep implementation notes can belong later.

The decision to adopt the interaction comes first.

A useful effect page should make rejection possible

There is a tendency in product pages to optimise every piece of information toward continuing the funnel.

For developer tools, I think there is another useful outcome: helping somebody decide quickly that a particular implementation is not right for their project.

Maybe the dependency is unnecessary.
Maybe the input model does not match.
Maybe the accessible fallback removes too much of the interaction's value.
Maybe the page simply does not need that much motion.

That is not failed product communication. It is informed adoption.

An effect library becomes easier to trust when its documentation helps developers exercise judgement instead of assuming that installation is always the desired outcome.

The question I would put to developers who regularly evaluate animation and interaction packages is this:

When you evaluate an interaction for production, what information can disqualify it before you install it: input assumptions, dependencies, accessibility fallback, rendering cost, framework constraints, or something else?

I suspect the answers differ considerably between creative developers, agency teams, product engineers, and people maintaining large applications. That difference is exactly why the information before installation matters.

Why Vault exists when React already has plenty of UI libraries

Jyoti Pathak — Thu, 13 Aug 2026 11:49:36 +0000

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.

The Missing Layer Between UI Components and Animation Tools

Jyoti Pathak — Thu, 13 Aug 2026 10:17:59 +0000

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.

Why We’re Building Vault as a Source-First Interaction Library

Jyoti Pathak — Tue, 11 Aug 2026 10:20:21 +0000

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

Your UI Kit Covers Components. Hyperiux Vault Adds Interaction Systems.

Jyoti Pathak — Thu, 06 Aug 2026 10:41:48 +0000

Your React site can pass review and still feel assembled. Your dialog works. The spacing is consistent. The hero, feature grid, pricing cards, FAQ and CTA are all present.

The missing piece may not be another component. It may be the code that decides how the page reacts to a pointer, turns scroll into a sequence, bridges a route change, or represents a real wait.

Call that backlog interaction debt: the work between a finished layout and an interaction system tested across devices, input types, motion preferences and performance budgets.

Hyperiux Vault addresses that gap by installing editable cursor, scroll, transition, loader and WebGL source into your project.

Vault sits beside your UI kit

Vault is a source-first library of interaction effects for React and Next.js. Its official catalog lists 115 effects: 32 free and 83 Pro. The catalog includes 16 cursor effects, 22 scroll effects, 6 page transitions, 3 loaders, and 19 WebGL/3D effects.

A larger catalog does not automatically mean better code. The counts matter because they reveal the catalog’s priorities.

Use shadcn/ui or your design system for dialogs, inputs, tables, tokens, and component states. Use Vault when the brief needs a cursor trail, a sequenced scroll section, a branded route transition, a loading treatment connected to real application state, or a WebGL scene.

Vault is not a replacement for a UI kit. It supplies pointer tracking, scroll sequencing, route-transition lifecycle work, loader visuals, and WebGL rendering that a foundational component library may not provide.

What “source-first” changes

Vault documents this CLI flow:
npx hyperiux init
npx hyperiux add phantom-image-trail

The CLI adds the selected effect’s files to your project and prompts before installing required dependencies. Depending on the effect, those files can include a React component, hooks, utilities, styles, animation setup, shaders, dependency notes, and usage examples.

That changes the workflow in concrete ways. You can edit a timing curve, pointer threshold, breakpoint, fallback, shader, asset, or DOM structure in the same repository as the rest of the product.

You also inherit the maintenance work. Installed code still needs review, tests, dependency updates, accessibility checks, cleanup verification, and profiling on real devices.

Source access is not the same as unrestricted ownership. Vault’s license documentation permits modification within projects covered by the applicable effect license or Pro plan, while Pro source redistribution and resale are restricted. The accurate promise is local source custody and editability under the applicable license.

Vault adds effect logic and supporting files to your project rather than hiding them behind a hosted component runtime. You should still audit imported packages, example assets, and external URLs before treating an installation as completely self-contained.

The competitor difference is catalog emphasis

“Who has animation?” is the wrong comparison. All four libraries overlap.

shadcn/ui is primarily organized around interface foundations such as dialogs, forms, navigation, tables, and feedback components. Its official component index is not organized around dedicated cursor, route-transition, or WebGL categories. That makes Vault complementary to the core job shadcn/ui performs.

Aceternity UI’s official categories index includes backgrounds, cards, shaders, loaders, 3D components, three entries under “Cursor & Pointer,” and five under “Scroll & Parallax.” As of August 6, 2026, Vault’s official taxonomy lists more cursor and scroll entries.

That does not prove that every Vault effect is better, or that Aceternity cannot implement the same techniques.

Magic UI includes Pointer, Smooth Cursor, Lens, Globe, Scroll Based Velocity, Scroll Progress, particles, beams, and animated backgrounds. Its current primary index does not use dedicated page-transition or loader headings. That is a taxonomy difference, not evidence that the library is incapable of those patterns.

Vault’s strongest defensible position is specific: editable interaction source with a catalog deliberately organized around cursor, scroll, transitions, loaders, and WebGL.

Catalog structure is only positioning. The source reveals whether that distinction survives contact with production.

Five effects and the production questions they expose

Phantom Image Trail
Phantom Image Trail leaves images behind pointer movement. The current public example detects coarse pointers and reduced-motion preferences, but its reduced-motion branch displays a notice instead of stopping the trail.

That is not a sufficient production fallback. Before shipping, disable or substantially simplify the animation, preserve native pointer meaning and focus visibility, keep the layer below controls and modals, and ensure no important content depends on hovering.
Source access matters here because the fallback is yours to inspect and fix.

Scroll Distortion
Scroll Distortion uses GSAP, Lenis, and Three.js to warp selected visuals during scroll.

It provides an existing implementation of scroll coordination, rendering logic, responsive behavior, and cleanup that your team can inspect and modify. Keep text and controls outside the distorted surface, reduce the effect on mobile, and avoid it on reading-heavy or utility pages.

Pixel Transition
Pixel Transition turns route changes into a pixel-grid dissolve. The documented version is Next.js App Router only, requires next-transition-router, and does not work in plain React or the Pages Router.

Use it only where a brief transition supports the brand. Keep it fast, restore focus after navigation, avoid artificial delay, and provide an instant or restrained reduced-motion path.

Numeric Tunnel Loader
Numeric Tunnel Loader uses GSAP, React Three Fiber, Drei, and Three.js. The public example advances its percentage with a local timer.

For production, replace that timer with real progress or use an indeterminate state. Add aria-busy, concise status text, and a reduced-motion alternative. A branded loader is useful only when it represents work that is actually happening.

Grid Tunnel
Grid Tunnel is a continuous React Three Fiber scene built around a vanishing-point grid.

Its official guidance recommends capping device pixel ratio, pausing offscreen and in hidden tabs, keeping meaningful content in HTML, and switching to a poster when the scene cannot maintain frame rate.

Local scene access is valuable here, but a mid-range phone reveals more about production readiness than a desktop preview.

When Vault is the right recommendation

Choose Vault when your project already has interface foundations and needs a specific interaction system whose pointer logic, scroll sequencing, route lifecycle, loading state, or rendering setup would otherwise start from a blank file.

Skip heavy effects when speed-to-action matters more than atmosphere. Dashboards, checkout, documentation, dense forms, and frequently navigated product flows often benefit from less choreography, not more.

An effect earns its place when it improves comprehension, feedback, hierarchy, or brand expression enough to justify its accessibility, performance, and maintenance costs.

A low-risk way to evaluate Vault is to browse the catalog, choose an effect marked free, install it, place it inside a real page, and test it with real content, keyboard navigation, reduced motion, touch input, and a mid-range phone.

Start with one interaction that earns its place. Then decide whether the rest of the page needs more.

Vault launch week starts today.

Jyoti Pathak — Mon, 06 Jul 2026 13:10:33 +0000

Vault launch week starts today.

Your website deserves better than looking like a beautiful PDF with a navbar.

Vault gives React and Next.js teams ready-to-use 3D, WebGL, scroll, cursor, and page transition effects they can install, customize, and ship.

Source-owned.
Motion-ready.
Built to make websites feel alive.