DEV Community: Jyoti Pathak

Animated Next.js Without Turning the Whole Page into a client component

Jyoti Pathak — Mon, 28 Sep 2026 14:38:43 +0000

You add a scroll reveal to the hero, so the component gets "use client".

Then the custom cursor needs pointer coordinates. The feature section needs layout measurements. A route transition needs navigation state. Eventually somebody puts "use client" at the top of page.tsx because the page is animated anyway.

Nothing immediately breaks.

That is what makes the pattern easy to keep.

For animation-heavy Next.js pages, "use client" usually belongs at the smallest practical boundary that genuinely needs state, effects, event handlers, DOM access, browser APIs, or an animation runtime.

The presence of animation is not, by itself, a reason to make the page a Client Component.

`"use client"` describes a boundary

In the App Router, pages and layouts are Server Components by default.

A file marked with "use client" establishes an entry point into the client-side module graph. Everything imported through that client entry point needs to be considered as part of that client-side architecture.

That is more useful than thinking of "use client" as an "animation mode."

For example, this is usually a suspicious boundary:

// app/page.tsx
"use client"

import Hero from "@/components/Hero"
import Features from "@/components/Features"
import Testimonials from "@/components/Testimonials"
import Footer from "@/components/Footer"

export default function Page() {
  return (
    <>
      <Hero />
      <Features />
      <Testimonials />
      <Footer />
    </>
  )
}

Maybe Hero tracks the pointer.

Maybe everything else is ordinary content.

The page-level directive now makes the route itself the client entry point even though most of the route has no browser dependency.

A more accurate architecture is:

// app/page.tsx
import AnimatedHero from "@/components/AnimatedHero"
import Features from "@/components/Features"
import Testimonials from "@/components/Testimonials"
import Footer from "@/components/Footer"

export default function Page() {
  return (
    <>
      <AnimatedHero />
      <Features />
      <Testimonials />
      <Footer />
    </>
  )
}

Then the component responsible for the browser behaviour establishes its own boundary:

// components/AnimatedHero.tsx
"use client"

export default function AnimatedHero() {
  // Pointer state
  // Effects
  // Browser APIs
  // Animation hooks

  return <section>{/* ... */}</section>
}

Now the architecture says something useful.

The route is server-owned. The interactive hero owns the runtime it actually requires.

What normally requires a Client Component?

Animation is too broad a category to answer this question.

A CSS transition is animation. So is a GSAP ScrollTrigger sequence. So is a continuously rendered WebGL scene.

Their runtime requirements are completely different.

A Client Component is commonly justified when the implementation needs things such as:

React state or client-side hooks
event handlers
window, document, or other browser APIs
DOM measurement
pointer or touch input
scroll listeners
observers tied to browser behaviour
imperative animation timelines
canvas rendering
WebGL

Even that list is contextual.

A hover effect implemented entirely with CSS does not need React client state because it moves. A keyframe animation does not suddenly require hydration because the transform is visually elaborate.

The implementation should determine the boundary.

Think in client islands

Consider a product page with:

an animated hero
ordinary product copy
a scroll-controlled feature sequence
testimonials
a WebGL product scene
a normal footer

Making the whole route a Client Component is certainly possible:

// app/product/page.tsx
"use client"

export default function ProductPage() {
  return (
    <>
      <Hero />
      <ProductIntro />
      <FeatureStory />
      <Testimonials />
      <ProductScene />
      <Footer />
    </>
  )
}

But three interactive regions do not require six regions to share the same runtime boundary.

The page can stay server-owned:

// app/product/page.tsx
import AnimatedHero from "./AnimatedHero"
import ProductIntro from "./ProductIntro"
import FeatureStory from "./FeatureStory"
import Testimonials from "./Testimonials"
import ProductScene from "./ProductScene"
import Footer from "./Footer"

export default async function ProductPage() {
  const product = await getProduct()

  return (
    <>
      <AnimatedHero title={product.title} />
      <ProductIntro product={product} />
      <FeatureStory />
      <Testimonials quotes={product.quotes} />
      <ProductScene />
      <Footer />
    </>
  )
}

Then the browser-dependent components establish boundaries where they are needed:

// AnimatedHero.tsx
"use client"

// FeatureStory.tsx
"use client"

// ProductScene.tsx
"use client"

This also makes the actual cost of each interaction easier to reason about.

The GSAP lifecycle belongs to the feature sequence. The WebGL loading strategy belongs to the scene. Pointer behaviour can change or disappear on coarse-pointer devices without turning the footer into part of the same architectural unit.

The rendered tree is not the module graph

A lot of confusion disappears once these two structures are separated mentally.

Your module graph might resemble:

page.tsx
├── ProductIntro
├── Testimonials
├── AnimatedHero
│   ├── "use client"
│   └── animation dependencies
└── ProductScene
    ├── "use client"
    └── WebGL dependencies

The user still sees one page:

<Page>
  <AnimatedHero />
  <ProductIntro />
  <FeatureStory />
  <Testimonials />
  <ProductScene />
  <Footer />
</Page>

Visual nesting does not require the runtime architecture to become one giant client graph.

This becomes especially useful when an interactive component needs to surround server-rendered content.

Pass data into the interaction

Splitting a page into client islands does not mean data fetching needs to move into those islands.

A Server Component can fetch the data:

// app/page.tsx
import AnimatedHeadline from "@/components/AnimatedHeadline"

export default async function Page() {
  const campaign = await getCampaign()

  return (
    <AnimatedHeadline
      eyebrow={campaign.eyebrow}
      title={campaign.title}
    />
  )
}

The Client Component receives the serializable values it actually needs:

// components/AnimatedHeadline.tsx
"use client"

type Props = {
  eyebrow: string
  title: string
}

export default function AnimatedHeadline({
  eyebrow,
  title,
}: Props) {
  return (
    <header>
      <p>{eyebrow}</p>
      <h1>{title}</h1>
    </header>
  )
}

The animation owns interaction behaviour without inheriting responsibility for unrelated server concerns.

This is also a cleaner debugging surface. Its inputs are obvious, its browser dependencies are local, and lifecycle cleanup has a much smaller place to hide.

A Client Component can wrap server-rendered content

Suppose you want an animated reveal wrapper around content that otherwise has no reason to become client-owned.

The Server Component can perform the composition:

// app/page.tsx
import RevealShell from "@/components/RevealShell"
import ProductDetails from "@/components/ProductDetails"

export default function Page() {
  return (
    <RevealShell>
      <ProductDetails />
    </RevealShell>
  )
}

The wrapper itself remains client-side:

// components/RevealShell.tsx
"use client"

export default function RevealShell({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <div className="reveal-shell">
      {children}
    </div>
  )
}

ProductDetails does not need "use client" merely because it appears visually inside RevealShell.

The important architectural detail is that RevealShell is not importing ProductDetails. The server parent composes the tree and supplies the content through children.

This pattern works well for things like reveal shells, interactive panels, disclosure systems, transition containers, and layout effects around otherwise server-owned content.

Motion, GSAP, and WebGL should not get identical treatment

Calling all three "animation" hides the useful differences.

Motion: inspect the API you are using

A Motion component that relies on interactive client behaviour can live inside a focused Client Component:

"use client"

import { motion } from "motion/react"

export function Card() {
  return (
    <motion.div whileHover={{ scale: 1.03 }}>
      Hover me
    </motion.div>
  )
}

Motion also provides motion/react-client for React Server Component environments:

import * as motion from "motion/react-client"

export function HeroTitle() {
  return (
    <motion.h1
      initial={{ opacity: 0, y: 16 }}
      animate={{ opacity: 1, y: 0 }}
    >
      Build the boundary around the behavior
    </motion.h1>
  )
}

This does not make every Motion API server-compatible.

Once the interaction depends on client hooks, gesture state, AnimatePresence, browser state, or similar behaviour, a Client Component boundary is still appropriate.

The presence of the motion package alone is not enough information to decide where "use client" belongs.

GSAP: keep the lifecycle with the sequence

Imperative GSAP work commonly interacts with DOM elements, layout, scroll state, and browser timing.

That makes a focused component a natural place for the runtime:

"use client"

import { useRef } from "react"
import { gsap } from "gsap"
import { useGSAP } from "@gsap/react"

gsap.registerPlugin(useGSAP)

export function FeatureSequence() {
  const scope = useRef<HTMLDivElement>(null)

  useGSAP(
    () => {
      gsap.from(".feature-card", {
        opacity: 0,
        y: 40,
        stagger: 0.12,
      })
    },
    { scope }
  )

  return (
    <div ref={scope}>
      <article className="feature-card">...</article>
      <article className="feature-card">...</article>
    </div>
  )
}

Putting GSAP in a smaller component does not magically make the animation cheap.

What it does is keep selectors, timeline ownership, setup, and cleanup attached to the feature responsible for them.

An imperative scroll sequence should not become infrastructure for an otherwise server-owned route just because it occupies one section of the page.

WebGL: isolate the subsystem

A Three.js or React Three Fiber scene has a different shape again.

A production scene may involve:

a canvas
a render loop
DPR decisions
shaders
textures
postprocessing
pointer input
resize handling
visibility detection
offscreen pausing

That usually deserves an obvious browser-side boundary.

The heading next to the canvas does not need WebGL. Neither does the body copy. Neither does the CTA.

A decorative canvas can be an isolated runtime inside a server-rendered hero instead of becoming the architecture of the entire hero.

`ssr: false` solves a different problem

A component requiring client execution and a component that should skip prerendering are not necessarily the same thing.

It is tempting to treat this as the standard solution for animation:

dynamic(() => import("./AnimatedThing"), {
  ssr: false,
})

But most animated components do not need SSR disabled.

For browser-heavy code that genuinely should only load on the client, a focused wrapper makes the decision explicit:

// components/ProductSceneClient.tsx
"use client"

import dynamic from "next/dynamic"

const ProductScene = dynamic(
  () => import("./ProductScene"),
  {
    ssr: false,
    loading: () => (
      <div aria-hidden="true">
        Loading visual...
      </div>
    ),
  }
)

export default function ProductSceneClient() {
  return <ProductScene />
}

The server-owned page can then import that wrapper:

// app/product/page.tsx
import ProductSceneClient from "@/components/ProductSceneClient"

export default function ProductPage() {
  return (
    <main>
      <h1>Product</h1>
      <ProductSceneClient />
    </main>
  )
}

With the App Router, ssr: false for next/dynamic belongs inside a Client Component rather than being used directly from a Server Component.

This arrangement makes all four decisions visible:

The page remains server-owned.
The wrapper marks the client boundary.
The browser-only implementation is dynamically loaded there.
Prerendering is disabled specifically for the code that does not benefit from it.

Doing this for a simple hover interaction would be unnecessary ceremony.

For a substantial WebGL subsystem, it can be a sensible architecture.

Small client boundaries are not a performance cheat code

There is an attractive oversimplification here:

Move "use client" lower and the page becomes fast.

No.

A narrower boundary can keep unrelated modules out of the client-side graph. It cannot rescue expensive code inside that boundary.

A neatly isolated WebGL component can still render too much.

A focused scroll sequence can still repeatedly measure layout.

A cursor trail can still produce unnecessary work on every pointer event.

An effect can still ignore prefers-reduced-motion, keep listeners alive after they are useful, update continuously while offscreen, or have no sensible interaction on touch hardware.

The architecture gives you a cleaner place to solve those problems. It does not solve them automatically.

For production animation, I would inspect at least these questions:

How much JavaScript does this interaction add?
Are event listeners, observers, and timelines cleaned up?
Does work continue while the effect is offscreen?
What happens on touch and coarse-pointer devices?
Is layout being measured repeatedly?
Does the render loop actually need to run continuously?
What happens when the user requests reduced motion?
How does it behave on a mid-range phone?
Does meaningful content remain usable without the effect?
Are focus, keyboard behaviour, and semantics still correct?

Profile the production build.

A beautiful component tree is not a benchmark.

Source access makes this easier to inspect

This is also why editable interaction source can be useful in animation-heavy Next.js projects.

A source-first library lets the browser dependency remain visible instead of hiding the implementation behind a fixed abstraction.

For example, Hyperiux Vault provides interaction patterns for React and Next.js as editable source files. Different effects can use CSS, Motion, GSAP, canvas, Three.js, React Three Fiber, or other browser APIs depending on the implementation.

The useful question is therefore not:

"Is Vault client-side?"

It is:

"What does this particular effect require?"

If a scroll interaction performs browser measurement and owns an imperative timeline, the source can contain that client boundary.

If a WebGL scene owns a canvas and render loop, you can isolate it and adjust how it loads.

If a lighter effect has no equivalent requirement, it does not need to inherit the architecture of the heavier component next to it.

Source access becomes especially relevant once the demo meets a real application. You may need to change breakpoint behaviour, touch fallbacks, listeners, observers, cleanup, dependency scope, DOM structure, reduced-motion handling, stacking context, or offscreen behaviour.

Those decisions live in implementation code, not in an animation adjective.

Vault's installation documentation covers its current Next.js setup if you want to inspect that source-first workflow.

A practical test before adding `"use client"`

When a page contains several animated regions, I find this sequence more useful than asking whether the page is "interactive."

1. Name the browser dependency

Be specific.

"Animation" tells you almost nothing.

"Pointer coordinates," "layout measurement," "useEffect," "ScrollTrigger," "window," "canvas," and "WebGL" tell you considerably more.

2. Put the boundary near that dependency

If the hero is the only component tracking the pointer, let the hero own the boundary.

If one feature story contains a GSAP timeline, keep that timeline there.

Do not split components merely to chase the smallest possible file. The goal is for runtime ownership to match the part of the interface creating the requirement.

3. Leave server-owned work outside when it naturally belongs there

Product data, editorial copy, testimonials, metadata, and ordinary layout do not need to inherit the runtime requirements of an adjacent canvas.

Fetch and compose on the server where appropriate. Pass serializable data into the interaction.

If a client-side wrapper needs server-rendered content inside it, compose through children.

4. Use the lightest runtime that actually matches the interaction

Sometimes CSS is enough.

Sometimes Motion is the cleanest fit.

Sometimes the interaction genuinely needs GSAP's imperative timeline model.

Sometimes a WebGL scene deserves its own browser-only loading strategy.

Visual ambition does not tell you which one is correct.

5. Test the behaviour, not the component diagram

Check the production build on real devices.

Test touch.

Test reduced motion.

Test keyboard navigation.

Check cleanup.

Look for offscreen work.

Inspect loading states.

Throttle the device or try hardware that is less forgiving than your development machine.

Several focused Client Components are not necessarily evidence of a fragmented application. They may simply describe the application accurately.

The server owns the parts that do not need browser execution. The browser owns the interactions that do.

That is a much more useful role for "use client" than putting it at the top of a route because something somewhere happens to move.

CSS, Motion, or GSAP? I Choose by Who Owns the Animation

Jyoti Pathak — Mon, 21 Sep 2026 08:12:31 +0000

A button changes on hover. A modal needs to finish leaving before React removes it. A launch page pins the viewport while several elements enter, overlap, and hand control back to normal scrolling.

All three are “animations,” but that label does not tell me which tool to reach for.

When I evaluate an interaction for Hyperiux Vault, I find one question more useful than asking whether the animation is simple, intermediate, or advanced:

Who owns the interaction?

If the browser already owns the relevant state, I usually evaluate CSS first.

If the animation is a consequence of React state, presence, layout, or gestures, I look at Motion.

If the authored sequence itself needs explicit control, especially across several elements or against scroll, I look at GSAP.

And if movement does not improve feedback, continuity, hierarchy, or storytelling, I leave it static.

That model is more useful than treating CSS, Motion, and GSAP as levels you unlock.

Start with ownership, not complexity

The familiar rule is:

Simple animation → CSS

Medium animation → Motion

Advanced animation → GSAP

The hierarchy falls apart as soon as visual complexity and implementation complexity stop matching.

A shared-layout transition between two React states can look elaborate. Cards reorder, an active indicator moves between controls, and one surface appears to grow into another. Motion has layout and layoutId APIs specifically for animation that follows changed layout in React.

Meanwhile, a hero sequence might contain nothing more technically exotic than opacity and transforms. But if six elements need to overlap at deliberate moments, moving one beat earlier should not require recalculating five unrelated delays. A GSAP timeline gives that timing a shared model.

The second animation may look simpler while needing more explicit choreography.

Visual complexity did not route those examples. Their ownership model did.

The interaction ownership model

I use four starting points.

Who owns the interaction?	What that usually means	First tool to evaluate
The browser	Hover, focus, pressed state, straightforward visual state changes, predefined keyframes	CSS
The React component	Mount/unmount, conditional rendering, layout changes, shared elements, gestures	Motion
The choreography	Several elements share timing, sequence control matters, scroll progress drives an authored composition	GSAP
Nobody needs to	Movement adds no useful feedback, hierarchy, continuity, or narrative	No animation

This is a routing model, not a capability table. GSAP can animate hover states. Motion can handle scroll. CSS can produce sophisticated sequences.

The question is which abstraction describes the interaction with the least unnecessary machinery.

Browser-owned state: evaluate CSS first

A button already has hover and focus states. CSS already understands them.

If the design asks for the icon to move four pixels, the background to change, and the button to scale slightly on pointer hover, moving that behaviour into a JavaScript animation system usually adds an abstraction without adding much control.

Transitions fit naturally because the state already exists in the browser:

.button {
  transform: translateY(0);
  transition: transform 180ms ease;
}

.button:hover {
  transform: translateY(-2px);
}

Keyframes extend the same idea when the browser should run a predefined sequence rather than interpolate between two states.

CSS stops being the obvious answer when orchestration starts leaking into the implementation.

If adjusting one duration forces you to recalculate delays elsewhere, time has become a relationship between elements. If React is removing the node you are trying to animate, the problem now includes component lifecycle. If JavaScript keeps measuring layout so that CSS knows where something moved, another abstraction may describe the interaction more clearly.

Watch the orchestration instead of the visual ambition.

Component-owned state: evaluate Motion

Motion becomes particularly useful when movement follows state React already owns: what is mounted, what state is active, how layout changed, or which gesture is occurring.

A modal is the obvious lifecycle example.

React wants to stop rendering it when open becomes false. The interface may need the modal to remain visible long enough to finish its exit transition. Motion's AnimatePresence exists around this exact boundary, allowing exiting elements to animate before they are removed from the DOM.

Layout changes are another strong signal. Adding Motion's layout prop lets an element animate between layouts after a React render changes its position or dimensions. layoutId can connect matching elements between states.

That is a different kind of problem from running a timed sequence. The important event is the render and the resulting layout change.

Motion also provides gesture APIs for hover, tap, focus, and drag, keeping interaction state close to the component producing it.

This is why I do not think of Motion as “GSAP Lite.” Its advantage is not that it sits halfway up an animation difficulty ladder. Its abstractions line up well with component-owned interactions.

Motion also supports scroll-triggered and scroll-linked animation, so the presence of scroll alone does not route the work to GSAP.

A viewport reveal and a pinned, scrubbed product story both involve scrolling. Only one makes scroll position part of a larger choreography.

Choreography-owned state: evaluate GSAP

Sometimes the timeline becomes a first-class part of the design.

Imagine a launch hero:

a product render enters;
a mask begins revealing before the first movement ends;
the heading starts against that overlap;
supporting copy appears at a named beat;
the whole sequence needs to be paused or replayed during development.

The individual animations are simple. Their relationships are not.

A gsap.timeline() gives those relationships a shared playhead. Timing can be positioned relative to other moments instead of encoded as independent delays scattered across components.

Scroll choreography strengthens the case.

ScrollTrigger supports behaviours such as triggering, scrubbing, and pinning. If a feature story keeps a claim fixed while product states change against scroll progress, the implementation now coordinates pin duration, scroll distance, sequencing, and the return to normal document flow.

At that point, time, or scroll mapped onto time, is part of the system.

React still owns the component lifecycle

Using an imperative animation API does not make React lifecycle irrelevant.

GSAP provides useGSAP() through @gsap/react to scope animation work and clean up GSAP objects created during the hook's execution when that scope is reverted. Animations created later in event handlers may need contextSafe() so they participate in the same cleanup model.

In a Next.js App Router setup, a component using useGSAP() needs the appropriate client boundary.

This matters more than it does in a demo. Route changes, repeated mounts, listeners, and ScrollTriggers can expose lifecycle mistakes that are invisible during a single polished run-through.

A worked example: an animated product filter

Suppose a React product page has a filter panel.

Opening the filter changes the panel state. Selecting an option reorders the product cards. An active filter indicator moves between controls. On narrow screens, the filter becomes a modal sheet.

There are plenty of animations here. The first question is still ownership.

The button's hover treatment is browser-owned. CSS is sufficient.

The panel appears and disappears because React state changes. The mobile sheet needs an exit before unmounting. The grid reflows after filtering, and the active indicator changes layout with the selected state.

Those requirements are component-owned, so Motion is the first library I would evaluate.

Now imagine the design changes.

Selecting a filter launches a deliberately authored sequence: the current cards compress, the heading shifts, a loading treatment crosses the grid, new cards enter in staggered groups, and the entire sequence needs exact replayable timing.

The interaction has changed categories. React still determines which products exist, but choreography is now carrying a significant part of the design. GSAP becomes a more reasonable candidate.

The visible interface may have changed only slightly. The ownership of the motion changed a lot.

That is the decision I care about.

The tools still overlap

Ownership narrows the choice; it does not settle every project decision.

A basic viewport reveal can reasonably be built with CSS and browser APIs, Motion, or GSAP depending on the surrounding system. A team already using GSAP heavily may prefer to keep a small additional animation inside the same mental model. A Motion-heavy application may have little reason to introduce another dependency for one sequence that Motion already expresses clearly.

Maintenance matters alongside capability.

The first tool to evaluate is not automatically the tool you must use.

Interaction	First evaluation	Reconsider when…
Hover/focus/press state	CSS	Runtime coordination appears
Mount/unmount transition	Motion	The sequence extends far beyond component lifecycle
Layout/shared element	Motion	Authored timing dominates the interaction
Multi-element timed sequence	GSAP	The sequence is simple enough to remain declarative
Pinned scroll narrative	GSAP	A simpler non-pinned treatment communicates the same idea
Decorative motion with no useful job	None	There is a reason for the movement

Production changes the answer

Tool selection does not solve the mobile version, reduced motion, cleanup, or runtime cost.

I usually run the chosen interaction through three additional gates.

1. Does the input still exist?

A hover-led effect has no direct equivalent on a touchscreen. A desktop cursor interaction may need to disappear or become a different interaction entirely.

Pinned scrolling also deserves a mobile rethink. A wide-screen composition can keep a claim fixed while evidence changes beside it. Compressing the same behaviour into a narrow viewport can leave the user dragging through several screens of artificially constrained content.

The fallback needs to be designed, not merely disabled.

2. What happens when motion should be reduced?

The prefers-reduced-motion media feature gives the interface a signal that the user has requested less non-essential movement.

That does not necessarily mean replacing every transition with zero duration.

A large pan, parallax effect, or scroll-linked camera move may deserve a static alternative. A subtle opacity transition may still communicate a state change without producing the same motion burden.

The static state also needs to remain readable and usable when animation never runs.

3. What work survives after the animation?

Check what continues running when the interaction moves offscreen. Check whether listeners, observers, timelines, and ScrollTriggers are cleaned up. Look for repeated layout measurement and unnecessary continuous work.

A demo can hide all of this because demos are unusually polite environments.

Production pages are not.

This is how Vault approaches dependencies too

The same ownership logic influences how we think about interactions inside Hyperiux Vault.

The catalogue does not force every effect through one animation engine. Dependencies vary by effect: an interaction may use CSS, Motion, GSAP, browser APIs, or a graphics stack when the behaviour actually requires it.

The Vault dependency model exposes those dependencies at the effect level.

CSS, Motion, and GSAP can all be used without Vault. Vault becomes relevant when you have already decided that a page needs a particular interaction and would rather start from an implementation than rebuild its behaviour from an empty component.

Because the effect lands as editable source in the project, the surrounding decisions can still change: timing, layout, breakpoints, interaction behaviour, reduced-motion handling, and whatever else the final product requires.

The rule I keep

When choosing between CSS, Motion, and GSAP in React, I ask who owns the behaviour.

If the browser already owns the state, CSS is difficult to beat for clarity.

If the animation follows the component tree, Motion gives React concepts an animation model that fits them closely.

If the sequence itself needs authored control, GSAP makes that choreography explicit.

And if nobody can explain what the movement is helping the user understand, I leave it out.

The tool follows the interaction.

That order is much easier to maintain than choosing an animation library first and asking the interface to justify it afterward.

Browse React interaction effects in Hyperiux Vault →

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.

DEV Community: Jyoti Pathak

Animated Next.js Without Turning the Whole Page into a client component

"use client" describes a boundary

What normally requires a Client Component?

Think in client islands

The rendered tree is not the module graph

Pass data into the interaction

A Client Component can wrap server-rendered content

Motion, GSAP, and WebGL should not get identical treatment

Motion: inspect the API you are using

GSAP: keep the lifecycle with the sequence

WebGL: isolate the subsystem

ssr: false solves a different problem

Small client boundaries are not a performance cheat code

Source access makes this easier to inspect

A practical test before adding "use client"

1. Name the browser dependency

2. Put the boundary near that dependency

3. Leave server-owned work outside when it naturally belongs there

4. Use the lightest runtime that actually matches the interaction

5. Test the behaviour, not the component diagram

CSS, Motion, or GSAP? I Choose by Who Owns the Animation

Start with ownership, not complexity

The interaction ownership model

Browser-owned state: evaluate CSS first

Component-owned state: evaluate Motion

Choreography-owned state: evaluate GSAP

React still owns the component lifecycle

A worked example: an animated product filter

The tools still overlap

Production changes the answer

1. Does the input still exist?

2. What happens when motion should be reduced?

3. What work survives after the animation?

This is how Vault approaches dependencies too

The rule I keep

What an Interaction Library Should Tell You Before You Install Anything

The information before installation has a different job

A five-part pre-install check

1. What job does the interaction perform?

2. What environment or input does it assume?

3. What does adoption add to the project?

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

5. What could disqualify the interaction before installation?

The same framework produces very different answers

Numeric Tunnel

Fractal Glass

Standardisation should make differences easier to compare

Where the install command should sit in the decision

A useful effect page should make rejection possible

Why Vault exists when React already has plenty of UI libraries

UI libraries give you the pieces

Animation libraries solve a different part of the problem too

An interaction can be larger than the element you see moving

This is where Vault is different from a traditional UI library

Why provide a starting implementation instead of a recipe?

Source-first matters because interactions rarely stay untouched

Vault does not need UI libraries to be inadequate

The Missing Layer Between UI Components and Animation Tools

The useful boundary is not always the component

Consider a pinned scroll section

Sometimes the reusable unit is the behaviour

Why source ownership matters here

A useful way to decide

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

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

Vault sits beside your UI kit

What “source-first” changes

The competitor difference is catalog emphasis

When Vault is the right recommendation

Vault launch week starts today.

`"use client"` describes a boundary

`ssr: false` solves a different problem

A practical test before adding `"use client"`