DEV Community: Jyoti Pathak

Why Your React Animations Feel Slow Even at 60 FPS

Jyoti Pathak — Thu, 22 Oct 2026 14:26:35 +0000

Why Your React Animations Feel Slow Even at 60 FPS

You open the Performance panel. The animation is running around 60 FPS. There are no spectacular red warnings, nothing is visibly freezing, and your laptop is barely interested.

Yet the interaction still feels slow.

The cursor seems to chase the pointer instead of following it. A scroll reveal arrives just after you expect it. A draggable card has a slightly rubbery disconnect from your hand. A menu technically animates smoothly, but opening it feels heavier than clicking the same control without motion.

This is where an FPS counter can send debugging in the wrong direction.

60 FPS tells you how many frames arrived. It does not tell you whether they arrived well.

Animation quality is a combination of frame consistency, input latency, browser rendering work, JavaScript execution and the actual motion decisions you made. React can participate in those problems, but “React is slow” is rarely a useful diagnosis.

The better question is: what kind of slow are you looking at?

60 FPS Is a Target, Not a Diagnosis

On a 60 Hz display, the browser gets a new refresh opportunity roughly every 16.7 milliseconds. During that window it may need to execute JavaScript, recalculate styles, perform layout, paint pixels and composite layers before the updated frame reaches the display.

That is why 60 FPS became a familiar target for interface animation. A consistently delivered frame roughly every 16.7 ms can look smooth on a 60 Hz display.

The important word is consistently.

Imagine an FPS overlay reports an average around 60 over a measurement window. That number does not tell you whether individual frames were evenly spaced. A sequence with occasional slow frames followed by quicker frames can have a respectable average while still producing visible hitching.

Perceived motion follows the spacing of frames, not the optimism of the average.

This is also why hardcoding your animation around an assumption of exactly 60 updates per second is fragile. Displays running at 120 Hz and 144 Hz are common enough that requestAnimationFrame() may be called at those rates instead. MDN explicitly recommends using the timestamp provided to the callback when calculating animation progress.

let start;

function animate(timestamp) {
  if (start === undefined) {
    start = timestamp;
  }

  const elapsed = timestamp - start;
  const progress = Math.min(elapsed / 600, 1);

  element.style.transform = `translateX(${progress * 200}px)`;

  if (progress < 1) {
    requestAnimationFrame(animate);
  }
}

requestAnimationFrame(animate);

The animation above is based on elapsed time rather than “move three pixels every frame.” That distinction keeps the duration stable when the display refresh rate changes.

You can read more about the behavior of requestAnimationFrame() on MDN.

Your Browser Has More Work to Do Than Draw the Animation

When an element changes visually, the browser does not simply receive your new value and teleport pixels into place.

Depending on what changed, it can move through several stages: style recalculation, layout, paint and composition. The amount of work depends partly on the CSS property being animated.

Animating something that changes geometry, such as width, left or margin, can require the browser to recalculate layout and repaint. Properties such as transform and opacity can often avoid layout and be handled later in the rendering pipeline.

Consider a simple horizontal movement.

// Can require layout work as the value changes
<div style={{ left: `${x}px` }} />

// Usually a better fit for visual movement
<div style={{ transform: `translateX(${x}px)` }} />

That does not mean transform is a magic performance keyword. You can animate only transforms and still build a sluggish interaction if each frame also performs expensive JavaScript, reads layout repeatedly, updates a large React subtree, draws an expensive canvas scene or runs several competing effects.

The property is one part of the frame. MDN has a useful breakdown of the browser rendering waterfall and animation property costs.

The practical debugging question is not just “Am I getting 60 FPS?” It is “What work has to complete before each visible update?”

React Can Make the Animation Compete With Your Application

React state is a great way to express application state. It is not automatically the best place to store every intermediate pixel of an animation. Suppose a pointer-following element writes its coordinates into component state for every pointermove event:

import { useState } from "react";

export default function Follower() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  return (
    <div
      onPointerMove={(event) => {
        setPosition({
          x: event.clientX,
          y: event.clientY,
        });
      }}
    >
      <div
        className="follower"
        style={{
          transform: `translate3d(${position.x}px, ${position.y}px, 0)`,
        }}
      />
    </div>
  );
}

There is nothing inherently invalid about this code. The relevant question is what happens around it.

Every state update schedules React work. If Follower is isolated and the surrounding tree is cheap, the result may be perfectly acceptable. If the update causes substantial component work while other JavaScript is also running, you have made your animation share main-thread time with work that may not need to happen every frame.

For transient per-frame values, a ref or an animation system can sometimes keep React responsible for the meaningful state transition while letting interpolation happen outside repeated component renders.

import { useEffect, useRef } from "react";

export default function Follower() {
  const followerRef = useRef(null);
  const target = useRef({ x: 0, y: 0 });
  const current = useRef({ x: 0, y: 0 });

  useEffect(() => {
    let frameId;

    const tick = () => {
      current.current.x +=
        (target.current.x - current.current.x) * 0.18;

      current.current.y +=
        (target.current.y - current.current.y) * 0.18;

      if (followerRef.current) {
        followerRef.current.style.transform =
          `translate3d(${current.current.x}px, ${current.current.y}px, 0)`;
      }

      frameId = requestAnimationFrame(tick);
    };

    frameId = requestAnimationFrame(tick);

    return () => cancelAnimationFrame(frameId);
  }, []);

  return (
    <div
      onPointerMove={(event) => {
        target.current.x = event.clientX;
        target.current.y = event.clientY;
      }}
    >
      <div ref={followerRef} className="follower" />
    </div>
  );
}

This is not a rule that says “never animate through React state.” It is a separation-of-responsibilities question.

If a value exists mainly to produce another visual frame a few milliseconds later, ask whether the entire React render path needs to know about every intermediate value.

Profile before rewriting it.

`requestAnimationFrame()` Does Not Make Expensive Work Cheap

Moving code into requestAnimationFrame() is another optimization that can feel more powerful than it is.

requestAnimationFrame() tells the browser you want to run a callback before an upcoming repaint. It gives your animation work a browser-aware scheduling mechanism. It does not reduce the amount of work inside the callback.

This can still be expensive:

function tick() {
  const cards = document.querySelectorAll(".card");

  cards.forEach((card) => {
    const rect = card.getBoundingClientRect();

    card.style.transform =
      `translateY(${window.innerHeight - rect.top}px)`;
  });

  requestAnimationFrame(tick);
}

requestAnimationFrame(tick);

Now you are querying elements, measuring layout and writing styles repeatedly. Put enough work in there and rAF will faithfully schedule an expensive callback every time the browser gives you the chance.

The useful question is:

What am I asking the browser to do inside each frame?

Cache what can be cached. Avoid unnecessary layout measurement inside hot loops. Keep cleanup explicit. Stop loops that no longer have a reason to run.

requestAnimationFrame() is a scheduler, not absolution.

Sometimes the Performance Problem Is Actually a Motion Problem

This is the category that profiling tools cannot solve for you. An interaction can be computationally cheap, maintain a steady frame rate and still feel slow because you told it to move slowly.

Imagine a cursor follower using this interpolation:

current += (target - current) * 0.05;

The browser may render it beautifully. No dropped frames. No expensive layout. No large React commits. It can still feel like the cursor is dragging a reluctant ghost behind it.

Change the interpolation:

current += (target - current) * 0.22;

The computational cost is effectively the same, but the interaction feels radically more immediate.

The same problem appears with animation durations, easing curves and springs. A navigation overlay with a long ease-in can feel resistant because the first part of the motion barely moves. A spring with too little stiffness or too much settling can make a button feel mushy. A parallax layer that deliberately trails scroll position may cross the line from depth into input lag.

A perfectly rendered delay is still a delay.

This matters because developers often respond to that feeling by optimizing code that is already fast enough. They memoize components, switch libraries or reach for will-change, only to discover that the animation still feels heavy.

Before doing that, temporarily shorten the duration or remove smoothing. If the interaction suddenly feels right while the performance trace barely changes, you found a motion-design problem rather than a rendering bottleneck.

Input-Coupled Motion Exposes Latency Faster

Not all animation has the same relationship with the user.

A decorative background can arrive slightly late without anyone having a precise expectation for where it should be. A button pressed under a cursor is different. So is dragging, scrolling, scrubbing or moving a custom pointer.

The user's hand provides a reference signal.

If their pointer is here and your visual follower is consistently there, the delay is obvious. If their finger moves a card and the card takes time to catch up, they feel the gap before they think about it technically.

This is why scroll smoothing deserves restraint. Smoothing the visual response can create a deliberate sense of weight, but too much of it makes the page feel as though scrolling has been routed through syrup.

The same applies to cursor trails. A trailing layer can be expressive while the actual clickable interaction remains immediate. Trouble starts when decorative latency leaks into controls that are supposed to feel direct. For input-driven effects, profile responsiveness and inspect your interpolation before chasing raw FPS.

“Use Transform and Opacity” Is Good Advice With Missing Footnotes

For many DOM animations, transform and opacity are sensible first choices because they can avoid the layout work triggered by geometry-changing properties. They should not become a superstition.

A fullscreen blur, huge translucent layer, complex SVG filter, large shadow or high-resolution canvas may still cost real rendering time even if its position changes through transform. A page running five independently smooth animation loops can become expensive when they all operate together.

Production pages are ecosystems. Your effect does not get a private browser.

This becomes especially noticeable on marketing sites where animation lives beside analytics, hydration, images, video, sliders, third-party scripts and application code. An isolated CodePen can tell you whether the effect works. It cannot tell you what happens after the effect moves into the page that has to ship.

Profile Frame Time, Not Just the Counter

When an animation feels wrong, resist the urge to start changing code randomly.

Reproduce the issue in the environment where it actually matters. Use a production build when possible. Development tooling and extra checks can distort performance characteristics.

Then record the interaction in your browser's Performance panel.

Look at what is occupying the main thread around the problematic frames. Is there a large JavaScript task? Repeated style recalculation? Layout work? Expensive paint? A React render arriving at exactly the wrong moment? Multiple callbacks continuing after their sections have left the viewport?

You are trying to identify a category of failure before choosing a fix.

A useful diagnostic table looks like this:

What you feel	Inspect first
Animation visibly jumps	Frame timing, long JavaScript tasks, layout and paint
Motion is smooth but follows input late	Smoothing, interpolation, input handling and main-thread work
Animation struggles while UI data changes	React renders and competing JavaScript
Works on desktop, struggles on phone	CPU/GPU cost, image/canvas work and concurrent effects
Smooth everywhere but still feels heavy	Duration, easing, distance and spring tuning

For deeper diagnostics, browsers are also gaining visibility into Long Animation Frames, which can help identify work contributing to long frames. Treat it as an additional signal rather than the one universal profiling API; support and tooling still deserve checking for your target browsers.

Test the Page, Not the Demo

An animation should be judged in the page where it will live.

That means testing it beside the real navigation, typography, images, scripts and adjacent interactions. It also means testing the actual devices you care about rather than using a high-end development machine as your minimum specification.

Mobile changes more than available processing power. Pointer assumptions disappear. Viewports become shorter. Touch scrolling behaves differently. Effects that feel appropriately restrained with a mouse can become annoying when attached to every finger movement.

Offscreen work matters too. If a canvas render loop or animation keeps producing frames after the user has left the section, it is still spending resources even though it contributes nothing to the current experience.

The production checklist is therefore broader than “does it hit 60?”

Ask whether the effect stops when appropriate. Ask whether it still reads correctly without motion. Check prefers-reduced-motion where the interaction calls for an alternative. Verify keyboard and touch behavior where controls are involved.

And test the whole page.

Source Access Is Useful Because Performance Decisions Are Contextual

This is also where reusable animation patterns get interesting.

A polished demo can give you the right interaction idea, but production usually requires changing something: timing, breakpoint behavior, scroll distance, pointer behavior, dependencies, cleanup, the number of animated elements, or what happens when motion is reduced.

That is why Hyperiux Vault uses a source-first model for its React and Next.js interaction effects. The effect files land in your project, so the implementation can be inspected and tuned rather than treated as a sealed animation runtime. That does not make an effect automatically fast. It makes the decisions visible.

A scroll interaction may need different behavior on a short mobile viewport. A cursor system should not assume a fine pointer exists on every device. A WebGL scene has a very different rendering budget from a CSS text reveal. Those decisions belong in the implementation, not in a blanket promise that every animation is “optimized.”

Vault's Scroll Effects guidance makes the same production distinction: use properties appropriate for animation, avoid unnecessary layout reads during scroll, clean up timelines and listeners, and test the effect on a real mid-range device before treating the implementation as finished.

If you want a starting point rather than another empty component file, you can browse the React and Next.js interaction effects in Vault and adapt the source to the page that actually has to ship.

A Better Way to Debug “Slow” Animation

The next time an animation looks smooth in an FPS overlay but feels wrong under your hand, split the problem into separate questions.

Is the browser delivering frames consistently? Is expensive work happening during those frames? Is React doing work that does not need to happen at animation frequency? Is the visual response arriving late after input? Or is the easing itself simply telling the interface to feel slow?

Those failures can look similar from the outside, but they need different fixes.

60 FPS is useful evidence. It just isn't a verdict.

How to Keep Client-Side Animation From Taking Over Your Next.js Architecture

Jyoti Pathak — Wed, 14 Oct 2026 13:59:28 +0000

How to Keep Client-Side Animation From Taking Over Your Next.js Architecture

A single animated section can quietly change the architecture of an otherwise server-first Next.js page.

The hero needs pointer tracking, so "use client" appears at the top of the file.

Then a feature section needs a scroll timeline.

Later, someone adds a WebGL background that depends on browser APIs.

Before long, a page that originally needed a few interactive pieces has most of its component tree living behind a client boundary.

The animation still works.

The architecture has drifted.

In the App Router, "use client" defines a client module boundary. Once you cross it, modules imported into that client graph are part of the browser-side application.

So the useful rule is not:

Avoid client-side animation.

It is:

Put the client boundary around the smallest piece of interaction that actually needs the browser.

Everything else can stay server-first.

The problem is boundary creep

Most animation requirements are legitimate reasons to run code in the browser.

You might need:

window
pointer position
layout measurement
scroll progress
ResizeObserver
IntersectionObserver
an animation timeline
Canvas
WebGL
component state

None of those automatically mean the entire section or page should become a Client Component.

Imagine a product hero containing:

a heading
supporting copy
a CTA
pricing or product data
one animated visual

Only one part needs browser-side behavior.

If the whole hero gets "use client", the rendering boundary now reflects the needs of the animation rather than the needs of the interface.

That tends to spread.

Future developers see a client-owned section and add more client-only state to it. Server-renderable content becomes coupled to browser code. Animation dependencies start creeping upward through the component tree.

The better question is:

Which component actually owns the interaction?

That component should usually own the client boundary too.

Keep `"use client"` as low as practical

Consider this:

"use client"

export default function Hero() {
  return (
    <section>
      <h1>Build faster</h1>
      <p>Server-renderable marketing content.</p>
      <AnimatedProduct />
    </section>
  )
}

It works.

But the entire Hero is now part of the client module graph because one child needs animation.

A cleaner split is:

export default function Hero() {
  return (
    <section>
      <h1>Build faster</h1>
      <p>Server-renderable marketing content.</p>
      <AnimatedProduct />
    </section>
  )
}

Then isolate the animated piece:

"use client"

export function AnimatedProduct() {
  return <div>{/* animation logic */}</div>
}

Now the browser-specific behavior lives where it belongs.

The surrounding content can remain authored and rendered as Server Components while only the animated leaf enters the client graph.

This becomes much more useful when the animation also owns:

event listeners
observers
GSAP timelines
scroll triggers
pointer state
resize handling
cleanup

A good animation boundary tends to keep those responsibilities together.

Server-rendered content can still pass through a client wrapper

There is another pattern that is easy to miss.

Sometimes the animation needs to wrap content, but it does not need to own that content.

For example:

export default function Page() {
  return (
    <Reveal>
      <article>
        <h2>Server-rendered content</h2>
        <p>This content does not need client-side state.</p>
      </article>
    </Reveal>
  )
}

Then:

"use client"

export function Reveal({
  children,
}: {
  children: React.ReactNode
}) {
  return <div>{children}</div>
}

The important detail is the direction of composition.

The Server Component composes the content and passes it into the Client Component as children. The client module is not reaching back and importing a Server Component directly.

That pattern is useful for:

reveal wrappers
viewport-triggered sections
animated shells
carousels containing server-provided markup
interactive containers
transition wrappers

It lets the interaction stay client-side without moving all meaningful content there too.

Values crossing the boundary still need to follow React and Next.js serialization rules where applicable. Client-only functions and browser state should remain on the client side.

Before adding an animation library, ask whether CSS is enough

A surprising amount of motion does not need client-side JavaScript at all.

For example:

.card {
  transform: translateY(0);
  opacity: 1;
  transition:
    transform 220ms ease,
    opacity 220ms ease;
}

.card:hover {
  transform: translateY(-4px);
}

No hooks.

No animation runtime.

No lifecycle.

No "use client".

This is not an argument for replacing Motion or GSAP with CSS everywhere.

A hover state and a pinned scroll sequence are different problems.

The useful rule is to choose the smallest mechanism that solves the interaction.

CSS is often enough for:

hover feedback
color transitions
simple opacity
transforms
underlines
basic enter/exit effects where state is already available in CSS

A text reveal should not need a 3D pipeline.

Motion does not require client ownership of the whole section

Motion works naturally with React, so it is easy to let the client boundary expand around it.

That still is not necessary.

If one card needs gesture state or animation hooks, that card can own the client-side behavior.

The section containing twelve cards does not automatically need to become client-owned.

There is also an important current Next.js nuance here.

Motion provides motion/react-client for rendering Motion components from React Server Component contexts.

That does not mean all Motion behavior suddenly runs on the server.

Hooks, gesture logic, browser-dependent measurements, stateful interaction, and other client-only behavior still belong behind an appropriate Client Component boundary.

So think about what the component actually needs.

A simple animated element and a drag interaction have very different client requirements even if both use Motion.

Imperative animation needs a clear owner

Things become more architectural once you introduce imperative systems such as:

GSAP timelines
ScrollTrigger
custom observers
layout measurement
manual event listeners
resize logic

These all create lifecycle responsibilities.

The component that owns the affected DOM should usually own those responsibilities too.

Avoid one large page-level animation controller that reaches into unrelated sections.

Something like this is easier to reason about:

FeatureStory
├── owns its DOM
├── creates its timeline
├── creates its ScrollTriggers
├── handles its resize logic
└── cleans everything up on unmount

If another section has its own animation system, let that section own it separately.

Why?

Because page-level animation scripts tend to become brittle once the layout changes.

A section becomes conditional.

Another moves into a nested layout.

A mobile breakpoint changes the DOM.

One route preserves part of the tree while another unmounts it.

Suddenly the question "who cleans this animation up?" has no obvious answer.

Local ownership keeps animation architecture composable.

Do not make the animation timeline your page structure

Scroll animation is where this mistake shows up frequently.

Suppose a desktop section pins a product image while five text states appear as the user scrolls.

On mobile, you might not want the pinned experience at all.

The content should still work as:

Feature 1
Visual 1

Feature 2
Visual 2

Feature 3
Visual 3

The animation is a presentation layer over meaningful content.

It should not be the only thing holding that content together.

That gives you a much healthier fallback when:

the viewport changes
reduced motion is enabled
JS fails
the animation library changes
the creative direction gets simplified later

WebGL and Canvas deserve their own island

WebGL is an even stronger case for isolation.

A 3D hero might depend on:

Canvas
WebGL
Three.js
React Three Fiber
shaders
textures
pointer input
requestAnimationFrame
viewport dimensions
device pixel ratio

None of those requirements mean the heading or CTA should become client-owned.

A better architecture looks like this:

Server-rendered Hero
├── Heading
├── Copy
├── CTA
└── Client WebGL Island

The meaningful content remains ordinary HTML.

The renderer stays isolated.

This also makes it easier to:

provide a static fallback
simplify the effect on mobile
load the renderer later
reduce GPU work
remove the scene without rewriting the content structure

If the WebGL scene is expensive or below the fold, it may also be a good candidate for lazy loading.

`ssr: false` is useful, but it is not an architecture

When a package depends directly on browser APIs, the quickest reaction is often:

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

Sometimes that is exactly right.

But in the App Router, there is an important constraint:

ssr: false must be configured from a Client Component.

So for a browser-only renderer, the structure might look like:

// SceneClient.tsx
"use client"

import dynamic from "next/dynamic"

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

export function SceneClient() {
  return <Scene />
}

Your Server Component can then render SceneClient.

This is a useful browser-only boundary.

It still does not answer the rest of the architecture.

ssr: false tells Next.js not to server-render that component.

It does not decide:

how large the client island should be
whether the renderer should load immediately
where meaningful content belongs
who owns cleanup
whether mobile gets a fallback
whether reduced motion changes the effect
whether the animation should pause offscreen

Those are separate decisions.

A whole page made client-only because one component touches window is very different from a small isolated renderer that genuinely has no server representation.

Lazy loading and disabling SSR solve different problems

These two decisions are often bundled together, but they answer different questions.

Lazy loading asks:

When should this code be downloaded?

Disabling SSR asks:

Should this component render on the server at all?

A heavy scene below the fold might benefit from lazy loading.

A tiny client interaction at the top of the page probably does not need elaborate deferral.

A browser-only WebGL renderer may reasonably use both dynamic loading and ssr: false.

A simple Motion element may need neither.

Keeping these decisions separate prevents dynamic() from becoming a generic wrapper around every animation component.

Keep global animation providers smaller than you think

Once a site starts accumulating motion, it is tempting to create one global animation layer.

Some shared configuration is useful.

For example:

reduced-motion policy
transition defaults
common easing values
feature flags
interaction preferences

But shared policy does not mean shared implementation.

You probably do not need one global controller owning:

every ScrollTrigger
every observer
every timeline
the cursor
all page animations
every animation state

Next.js generally benefits from placing providers as deep as practical.

The same approach works well for motion.

If only the marketing section needs an animation provider, put it there.

If only one route has a custom cursor, do not make the root layout own it.

Keep global policy global. Keep local animation local.

Pause work the user cannot see

The client boundary is only the first part of the problem.

Once the animation has hydrated, you still need to decide when it should run.

A Canvas scene rendering in a hidden tab is still consuming resources.

An offscreen particle effect may still be animating.

A cursor trail may remain subscribed to pointer movement even after the relevant component is gone if cleanup is incomplete.

Depending on the effect, consider:

pausing render loops when the page is hidden
suspending expensive work while offscreen
disconnecting observers
removing event listeners
killing timelines on unmount
reducing visual complexity on mobile
lowering WebGL rendering cost
providing a static fallback

One animation doing unnecessary work may not be noticeable.

Five or six independently animated sections can make those assumptions add up quickly.

A practical architecture checklist

Before adding another animation to an App Router project, ask:

Question	Preferred direction
Can CSS solve it?	Keep it out of the client runtime
Does it need hooks, state, or browser APIs?	Use a small Client Component
Does it need an imperative timeline?	Give that timeline a local owner
Does it create listeners or observers?	Keep setup and cleanup together
Does it contain meaningful content?	Keep that content in HTML where possible
Does it require Canvas or WebGL?	Isolate the renderer
Is the renderer expensive or below the fold?	Consider lazy loading
Can it only exist in the browser?	Use an appropriate client-only boundary
Does it need shared motion policy?	Place the provider as deep as practical
Can it stop while hidden?	Pause it
What happens with reduced motion?	Simplify the interaction intentionally
What happens on touch devices?	Design a real fallback

This is the kind of checklist that stops animation from gradually becoming application architecture.

How source-first effects help with this

This is also where source-first interaction libraries can be useful.

For example, Hyperiux Vault provides React and Next.js interaction patterns as editable source.

The useful part from an architecture perspective is not simply that the effect exists.

It is that you can inspect:

where the client boundary begins
what dependencies the effect uses
how lifecycle and cleanup are handled
what should change for mobile or browser-only rendering

That makes it easier to fit an effect into your existing architecture instead of restructuring the application around an opaque package.

Vault's installation docs also distinguish effects that rely on things such as scroll state, pointer movement, layout measurement, timelines, Canvas, or WebGL from components that do not inherently require the same client-side footprint.

Vault does not solve Next.js architecture for you.

Next.js still defines the rendering model. Motion, GSAP, Three.js, React Three Fiber, and browser APIs still bring their own constraints.

Editable source simply makes those constraints easier to inspect and adapt.

The goal is not zero client JavaScript

A creative Next.js site is allowed to use the browser.

Some interactions genuinely require it.

Scroll-linked storytelling needs scroll state.

Dragging needs pointer input.

A page transition needs navigation state.

A custom cursor needs pointer events.

WebGL needs a renderer.

Trying to eliminate client JavaScript entirely would eliminate useful interaction along with it.

The goal is architectural proportion.

One hero measuring the viewport does not mean the page should become client-owned.

One Canvas component does not mean the route should disable SSR.

One animated wrapper does not mean its content needs to move into a client module.

Let the animation own the browser code it actually needs.

Then stop the boundary there.

If you want to inspect how more complex React and Next.js interaction patterns handle those boundaries in editable source, you can browse the Hyperiux Vault effects library.

A good interaction can be ambitious. Its client boundary does not have to be.

Why Some SaaS Websites Feel Custom Even When They Use Familiar UI Patterns

Jyoti Pathak — Tue, 13 Oct 2026 09:29:06 +0000

Most SaaS marketing sites are built from a familiar set of ingredients.

A hero section. Product screenshots. Feature cards. Social proof. Pricing. A few gradients. Maybe some motion on scroll.

None of those choices are bad. They are familiar because they work.

The problem is that a site can be beautifully designed and still feel like it could belong to almost any software company.

One reason is that the visual system gets plenty of attention while the interaction system stays generic.

For React and Next.js projects, this is the layer tools like Hyperiux Vault are built around. Vault provides source-first interaction patterns that can be brought into a project and adapted, rather than treating interaction as a fixed visual preset.

That matters because a custom-feeling SaaS website is rarely defined by how many animations it has.

It is defined by whether the page behaves in a way that makes sense for that specific product.

Visual customization only gets you so far

Suppose two SaaS companies use the same basic landing-page structure.

Both have:

a large headline
a product mockup
three feature sections
customer logos
testimonials
a pricing table
a final CTA

One company changes the font, colors, border radius, and illustration style.

The other changes how the page responds to the user.

Its product demo reacts to scrolling in a way that explains the workflow. Its feature sections use state changes to show cause and effect. Its navigation behaves consistently with the rest of the experience. Motion appears only where it helps the user understand something.

The second site is more likely to feel authored.

Not because its structure is radically different, but because its behavior is.

That is an important distinction for SaaS website interaction design.

The goal is not to make every website structurally unique. The goal is to make its interactions specific enough that they feel connected to the product.

Start with the job of the interaction

A common frontend workflow goes something like this:

Find a cool animation.
Add it to the page.
Adjust the colors.
Try to justify why it belongs there.

A better sequence starts one step earlier.

Ask what the interaction needs to accomplish.

Maybe the page needs to:

explain a process
show the difference between two states
keep one claim visible while evidence changes
show how one action produces a result
signal that something is interactive
create continuity between page sections
provide feedback after a user action

Once the job is clear, the implementation becomes easier to judge.

A sticky scroll section, for example, makes sense when the visitor benefits from keeping one idea fixed while examples or screenshots change beside it.

It makes much less sense when a simple vertical stack would communicate the same information more clearly.

The same applies to text animation, page transitions, custom cursors, WebGL scenes, and microinteractions.

The effect should follow the communication problem.

Not the other way around.

Interaction can explain things screenshots cannot

Static product screenshots are useful, but they usually show a result rather than the path to that result.

For many SaaS products, the path is the interesting part.

Imagine a workflow automation platform.

A screenshot might show:

a trigger
several conditions
a final action

But the feature becomes easier to understand if the site demonstrates the sequence:

Trigger fires → condition is checked → action runs → output changes

That does not require a huge animation system.

It could be a simple state transition.

The same principle applies to many products.

A developer tool can show code turning into an output.

An analytics platform can show how changing a filter affects the dashboard.

A collaboration tool can show how one person's action updates the shared workspace.

A CRM can demonstrate a lead moving through stages instead of showing a static pipeline.

In these cases, interaction is doing explanatory work.

A useful question is:

If this motion disappeared, would the visitor understand less?

If the answer is yes, the interaction is probably doing something valuable.

If the answer is no, it may still work as visual branding, but it is decoration rather than explanation.

Build a small interaction vocabulary

A website usually feels more deliberate when its interactions relate to each other.

This does not mean every animation should use the exact same duration or easing curve.

It means the page should have rules.

For example:

interface feedback happens quickly
narrative transitions happen more slowly
product demonstrations reveal state from left to right
hover effects are subtle
depth is reserved for important interactive areas
ordinary reading content stays still
large motion is used only for major moments

Those choices create a behavioral system.

Without that system, a page can start to feel like a collection of unrelated effects.

One section zooms.

Another fades.

The next one spins.

A card tilts.

The cursor changes shape.

Then a WebGL object appears because somebody found a shader demo they liked.

Each effect may be impressive by itself, but together they do not necessarily say anything.

A custom experience does not require maximum variation.

It requires coherence.

Pick a few places where interaction actually matters

One of the easiest ways to make motion feel cheap is to use it everywhere.

When every heading fades in, every card floats upward, every icon rotates, and every button stretches on hover, nothing has hierarchy.

A better approach is to identify the parts of the page that deserve stronger interaction.

For many SaaS sites, those might include:

The hero

The hero can introduce one interaction that helps visitors understand what the product does.

That could be:

an interactive UI preview
a workflow sequence
a state change
a controlled 3D scene
a short text treatment

The hero does not need five effects at once.

The core product story

If the product has a workflow that benefits from sequencing, this is often where scroll-linked interaction can help.

A claim can stay visible while screenshots or examples change.

A process can unfold step by step.

A comparison can transition between states.

Navigation

Navigation is small, but it is repeated constantly.

A well-considered menu transition, active state, focus state, or mobile navigation pattern can contribute more to perceived craft than another animated background.

Important feedback states

Buttons, tabs, filters, carousels, and interactive cards should communicate what changed.

These microinteractions are less dramatic than a WebGL hero, but users encounter them directly.

That makes them important.

Not every section needs motion

This is where restraint becomes part of interaction design.

Some content should simply be easy to use.

Pricing pages need comparison.

Forms need completion.

Documentation needs scanning.

Legal content needs readability.

FAQ sections often work perfectly well with basic disclosure behavior.

Adding animation to those areas does not automatically improve the experience.

It may only make the interface slower to process.

A useful rule is:

Use more interaction where the relationship between content changes. Use less where the user already knows what to do.

This is also why decorative loaders can become annoying.

A loader is useful when something is genuinely loading.

A loader that creates its own delay so the user can admire the animation is solving the wrong problem.

Reusable interaction does not have to look reusable

Developers often treat "custom" and "reusable" as opposites.

They are not.

Most frontend work already depends on reusable primitives.

Buttons are reused.

Grid systems are reused.

Form controls are reused.

Animation libraries are reused.

Utility classes are reused.

The important question is how much control you have over the result.

There are roughly three ways to approach a custom interaction.

Approach	Main advantage	Main trade-off
Build from scratch	Full control	More implementation work
Use a fixed preset	Fast starting point	Can be harder to adapt deeply
Start from editable source	Faster setup with local control	Still requires design and production judgement

This third model is where Hyperiux Vault fits.

Vault provides source-first interaction patterns for React and Next.js. Instead of depending on a single sealed runtime for every interaction, the relevant implementation can live inside the project and be adjusted to fit the real page.

That means a developer can change things that actually matter.

Not just colors.

They can adjust:

timing
breakpoints
triggers
layout assumptions
mobile behavior
dependencies
rendering decisions
reduced-motion behavior
how the effect fits into an existing design system

That is what turns a reusable starting point into something that can feel specific.

The starting code does not make the website custom.

The decisions you make after installing it do.

React and Next.js implementation still need boundaries

Once interactions become more ambitious, frontend architecture starts to matter.

Some interactions are simple enough to live entirely in CSS.

Others need:

scroll position
pointer tracking
layout measurements
animation timelines
browser APIs
Canvas
WebGL
requestAnimationFrame

In a Next.js application, those requirements affect where the client boundary should exist.

If a component needs browser APIs or interactive state, it belongs on the client side.

That does not mean the entire page should become a Client Component.

The browser-dependent part can stay isolated while surrounding content remains server-rendered.

This is especially useful for marketing pages.

Your headline, body copy, links, and SEO content do not need to become client-side just because one product demo tracks pointer movement.

Keep the interactive boundary as small as the implementation allows.

Official Next.js documentation covers this distinction between Server and Client Components in more detail:

https://nextjs.org/docs/app/getting-started/server-and-client-components

Mobile should preserve the idea, not necessarily the effect

A common mistake is treating mobile as a smaller desktop.

That becomes especially obvious with interaction design.

Desktop experiences may rely on:

hover
wide pinned layouts
custom cursors
horizontal movement
large WebGL canvases
complex pointer relationships

Those behaviors may not translate well to touch.

The answer is not always to force the same effect into a smaller viewport.

Instead, preserve the communication.

A pinned desktop story might become a normal vertical sequence.

A custom cursor can disappear.

A side-by-side interaction can become a swipeable or stacked layout.

A complex 3D background might become simpler or static.

The visual effect changes, but the meaning survives.

That is often the better responsive decision.

Reduced motion is part of the interaction system

Motion preferences also need to be considered before the final polish pass.

The browser exposes the prefers-reduced-motion media feature specifically so websites can respond when a user prefers less non-essential motion.

MDN documents the feature here:

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

The useful design question is not simply:

"Can we turn the animation off?"

It is:

"What does this section become when the animation is reduced?"

If a text reveal disappears, the full text still needs to be present.

If a scrolling sequence becomes static, the information still needs a logical reading order.

If motion communicates a state change, there should still be another visible way to understand that state.

The fallback is part of the design.

Performance should influence the interaction choice

There is no universal category of "safe animation."

A small opacity transition and a full-screen WebGL scene clearly have different costs.

Even within WebGL, two implementations can behave very differently depending on:

device pixel ratio
texture sizes
shader complexity
particle count
post-processing
number of render passes
whether the render loop keeps running offscreen

The same principle applies to scroll animation.

The problem is not simply "scroll animation is expensive."

The implementation matters.

Are you repeatedly measuring layout?

Are listeners being cleaned up?

Is expensive work running even when the section is no longer visible?

Are you testing a production build on real devices?

Does the mobile version need the same level of visual complexity?

Performance is not something to solve after the interaction is approved.

It is one of the constraints that should shape the interaction in the first place.

The most useful test is surprisingly simple

When reviewing an interaction, ask:

Could this exact effect belong to any competing SaaS website?

If the answer is yes, that does not automatically mean the effect is bad.

But it does mean the interaction itself is not doing much to make the website specific.

Then ask a few more questions:

Does this behavior explain something about the product?
Is it connected to the content around it?
Does it fit the brand's overall interaction language?
Can keyboard users still operate the interface?
Does the mobile experience preserve the same information?
Does the page still work with reduced motion?
Is the technical cost appropriate for the importance of the moment?

These questions are more useful than asking whether an animation looks impressive.

Custom-built is a result of decisions, not novelty

A SaaS website does not need a completely original layout, a custom rendering engine, or a different interaction on every screen to feel custom-built.

It needs decisions that are difficult to separate from the product itself.

The strongest interaction design usually combines:

familiar UI patterns
a small number of distinctive behaviors
product-specific demonstrations
consistent feedback
responsive adaptation
accessible fallbacks
sensible technical constraints

That is enough to make a familiar page structure feel authored instead of assembled.

Reusable code can absolutely be part of that process.

The important part is whether the implementation gives you enough control to shape the behavior around the product.

If you are working in React or Next.js and want starting points for that interaction layer, you can explore the effects in Hyperiux Vault.

The goal is not to make a website behave like nothing anyone has ever seen before.

It is to make it behave like it was built for this product, not just this layout.

Server Components and Interactive UI: Where Animation Actually Belongs

Jyoti Pathak — Mon, 12 Oct 2026 14:40:43 +0000

Server Components and Interactive UI: Where Animation Actually Belongs

A surprisingly common response to adding animation in a Next.js app is to put "use client" at the top of the component and move on.

The animation works. The warning disappears. The page ships.

Then the boundary spreads.

The hero becomes a Client Component because its heading animates. The section below imports the hero, so that joins the client graph. A layout imports an animation provider. Before long, a mostly static page has acquired a substantial client-side surface because three elements needed to move.

Animation does need the browser sometimes. It does not need the browser in the same way all the time.

That distinction is where the architecture gets interesting.

React Server Components cannot hold interactive state or register browser event handlers. They are rendered outside the browser environment and can be composed with Client Components where interaction is required. React explicitly recommends that composition model rather than treating an entire interface as client-side because one region is interactive.

For animation work, the useful question therefore isn't:

Is this component animated?

It is:

What does the animation need to know at runtime?

The answer usually tells you where it belongs.

Animation does not automatically mean `"use client"`

Start with the easiest case.

export function Hero() {
  return (
    <section className="hero">
      <h1 className="hero-title">
        Interfaces should move for a reason.
      </h1>
    </section>
  )
}

There is nothing preventing that heading from being animated with CSS.

.hero-title {
  animation: reveal 600ms cubic-bezier(.22, 1, .36, 1) both;
}

@keyframes reveal {
  from {
    opacity: 0;
    transform: translateY(16px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

@media (prefers-reduced-motion: reduce) {
  .hero-title {
    animation: none;
  }
}

The React component itself does not need state, an effect, window, a pointer position or a DOM reference.

The browser knows how to execute the CSS after the markup arrives.

Turning Hero into a Client Component would not make the animation more legitimate. It would merely move more code across the client boundary without giving React anything useful to do there.

This is the first useful decision rule:

If the movement can be expressed entirely from markup and CSS, the React component can often stay on the server.

Transitions, keyframe entrances, hover states and many decorative loops fit comfortably into this category.

CSS is still client-side behaviour in the literal sense that the browser performs it. It simply does not require client-side React.

That distinction saves a lot of unnecessary "use client" directives.

The client boundary starts where runtime knowledge starts

Now change the interaction.

Suppose the heading should reveal only when it enters the viewport.

The component needs IntersectionObserver.

Or the card should lean toward the pointer.

It needs pointer coordinates.

Or an expanding panel should animate between measured heights.

It may need DOM measurement.

Or a sequence runs through GSAP when a component mounts.

It needs lifecycle code and element references.

These are browser concerns. Current Next.js guidance places state, event handlers, lifecycle logic and browser-only APIs in Client Components.

A useful structure is therefore to keep the content-producing component on the server and introduce a smaller client-side animation boundary around the behaviour that genuinely needs one.

// app/page.tsx
import { AnimatedHero } from "@/components/animated-hero"

export default async function Page() {
  const project = await getFeaturedProject()

  return (
    <main>
      <AnimatedHero
        title={project.title}
        description={project.description}
      />

      <ProjectDetails project={project} />
    </main>
  )
}

// components/animated-hero.tsx
"use client"

import { useEffect, useRef } from "react"

export function AnimatedHero({
  title,
  description,
}: {
  title: string
  description: string
}) {
  const headingRef = useRef<HTMLHeadingElement>(null)

  useEffect(() => {
    const heading = headingRef.current
    if (!heading) return

    const animation = heading.animate(
      [
        { opacity: 0, transform: "translateY(16px)" },
        { opacity: 1, transform: "translateY(0)" },
      ],
      {
        duration: 600,
        easing: "cubic-bezier(.22, 1, .36, 1)",
        fill: "both",
      }
    )

    return () => animation.cancel()
  }, [])

  return (
    <section>
      <h1 ref={headingRef}>{title}</h1>
      <p>{description}</p>
    </section>
  )
}

The data fetching did not move into the animation component.

The page did not become client-rendered because a heading needed a reference.

Only the part that needs browser lifecycle crossed the boundary.

`"use client"` is a module boundary, not an animation annotation

This matters because "use client" affects more than the component where the string appears.

In Next.js, declaring a file as a Client Component establishes an entry point into the client module graph. Modules imported beneath that boundary become part of the client bundle as well. Next.js consequently recommends placing Client Component boundaries around specific interactive regions rather than unnecessarily high in the tree.

Consider this:

"use client"

import Hero from "./hero"
import ProjectGrid from "./project-grid"
import Footer from "./footer"
import AnimatedCursor from "./animated-cursor"

export default function HomePage() {
  return (
    <>
      <AnimatedCursor />
      <Hero />
      <ProjectGrid />
      <Footer />
    </>
  )
}

Only one part actually requires continuous pointer information, but the boundary now sits above the entire page.

A cleaner composition is:

import Hero from "./hero"
import ProjectGrid from "./project-grid"
import Footer from "./footer"
import AnimatedCursor from "./animated-cursor"

export default function HomePage() {
  return (
    <>
      <AnimatedCursor />
      <Hero />
      <ProjectGrid />
      <Footer />
    </>
  )
}

with:

// animated-cursor.tsx
"use client"

export default function AnimatedCursor() {
  // pointer interaction here
}

This sounds almost too obvious when reduced to four lines of code. It becomes less obvious in a real creative frontend where an animation provider, smooth-scroll instance, route transition system and several interaction components begin importing one another.

The boundary should follow behaviour, not visual composition.

A full-screen effect does not necessarily deserve a full-page client boundary.

Server Components can still provide the animated content

There is another architectural mistake hiding in the opposite direction: assuming that once a Client Component wraps something, all of its content also has to become client code.

It does not.

React and Next.js support composing server-rendered content into interactive Client Components. Next.js shows this with patterns such as passing a Server Component through children into a client-side modal.

That is useful for animation shells.

Imagine a horizontally animated gallery where the media metadata comes from the server:

// page.tsx
import { MotionTrack } from "./motion-track"
import { GalleryItems } from "./gallery-items"

export default function Page() {
  return (
    <MotionTrack>
      <GalleryItems />
    </MotionTrack>
  )
}

MotionTrack can be a Client Component because it measures its container, listens to input or drives transforms.

GalleryItems can remain server-rendered because its job is producing content.

// motion-track.tsx
"use client"

export function MotionTrack({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <div className="motion-track">
      {children}
    </div>
  )
}

The interactive wrapper does not need to take ownership of the data layer merely because it controls how the resulting DOM moves.

This composition becomes particularly valuable for animation-heavy interfaces. The server can remain responsible for fetching, content and structural markup while client islands coordinate only the pieces that need runtime behaviour.

Animation libraries make boundary placement easier to get wrong

Animation libraries encourage broad client boundaries because importing them is convenient.

A developer builds one MotionProvider, places it near the root, and suddenly every page has access to the same animation runtime.

Convenience can hide architecture.

Suppose a landing page contains:

a CSS reveal on the hero;
a scroll-triggered feature section;
an interactive cursor;
an ordinary pricing table;
a static footer.

Only two regions may require JavaScript animation at all.

There is little benefit in making the pricing table participate in the client graph simply because it visually sits between animated sections.

Instead:

export default function Page() {
  return (
    <>
      <Hero />
      <ScrollStory />
      <Pricing />
      <PointerExperience />
      <Footer />
    </>
  )
}

ScrollStory and PointerExperience become focused Client Components.

Everything else stays where its requirements naturally place it.

This also makes dependencies easier to reason about. A Three.js scene should not quietly pull a graphics stack into a general layout. A pointer effect should not force unrelated content through the same lifecycle. A GSAP implementation should have a clear mount point and cleanup path rather than existing as ambient page infrastructure simply because several elements move.

Hydration is part of the animation

Client Components still participate in the server-rendered initial experience in Next.js. On the initial load, Next.js can use their output to produce HTML, then hydrate them in the browser so event handlers and client behaviour become active.

That creates a design problem animation demos often hide.

What does the interface look like before the animation code is ready?

Consider an entrance reveal implemented like this:

.title {
  opacity: 0;
}

Then JavaScript mounts and animates it to opacity: 1.

If the JavaScript is late, interrupted, disabled or errors before initialization, your design has turned the primary heading into invisible content.

The static state should usually be valid on its own.

One approach is progressive enhancement: render the readable state, then add animation-specific setup once the client runtime is available.

For some interactions, CSS can handle the initial state. For others, the animation library provides mechanisms for controlling initial rendering. Either way, the decision deserves attention because hydration is not merely a React implementation detail when the first visual state depends on it.

A demo can assume initialization happens immediately. A production page has networks.

Scroll animation is mostly a browser problem

Scroll-driven experiences make the boundary especially clear.

A Server Component can generate:

the heading;
the article copy;
images;
project data;
section structure.

It cannot know the live viewport dimensions, current scroll position or whether a section has crossed an intersection threshold in the user's browser.

Those behaviours belong in a client layer.

That does not mean the entire storytelling section must be modeled as React state.

If the animation runtime can work through refs and transforms, keep React out of every frame. React can establish the structure while an imperative animation system handles continuous visual updates.

The lifecycle responsibilities still belong in the component:

useEffect(() => {
  const observer = new IntersectionObserver(callback)

  const element = sectionRef.current
  if (element) observer.observe(element)

  return () => {
    observer.disconnect()
  }
}, [])

The same principle applies to pointer listeners, ResizeObserver, animation frames and third-party timelines: setup belongs with cleanup.

The more creative the interaction becomes, the more valuable a small, explicit client island usually becomes. It gives the effect a place where its browser assumptions are visible instead of scattering them across the route.

Route transitions are a different problem again

Developers sometimes treat all motion as though it belongs at component mount.

Route transitions do not.

A route transition cares about navigation state, continuity between screens, potentially exit timing and whatever routing primitives the framework exposes. The relevant client boundary may therefore live higher than it would for an isolated hover effect.

That is fine.

“Keep every Client Component tiny” is not a useful absolute rule.

The better rule is to make the boundary as broad as the behaviour requires and no broader.

A cursor may need one isolated client component.

A carousel may need a client wrapper around its items.

A page-transition system may legitimately need a shared boundary around route content.

Architecture follows the scope of the interaction.

Browser input should influence the implementation

Pointer animation is another place where client-side code is obviously necessary but "use client" is only the first decision.

Once the effect owns pointer events, it also owns the questions that come with them.

What happens on touch?

Does the effect depend on hover as an affordance?

Does it continue running after the pointer stops?

Are listeners removed when the component unmounts?

If requestAnimationFrame drives interpolation, when does the loop stop?

A cursor trail that produces excellent screenshots but runs an unnecessary animation loop indefinitely is still unfinished frontend work.

The same scrutiny applies to WebGL. Once an effect requires canvas dimensions, DPR, pointer uniforms or a render loop, it belongs firmly in browser territory. The important architectural question then shifts from whether it is a Client Component to how much of the surrounding page needs to become one.

Usually, less than the demo suggests.

Reduced motion belongs at the same boundary

prefers-reduced-motion can be handled in CSS for CSS-driven motion:

@media (prefers-reduced-motion: reduce) {
  .animated {
    animation: none;
    transition: none;
  }
}

JavaScript-driven sequences need their own response.

A client animation component can read the media query and choose a static or reduced version rather than merely changing duration from 600 milliseconds to 200.

Reduced motion is not synonymous with no motion, and supporting the preference does not settle every accessibility question. Keyboard behaviour, focus, semantics and whether essential information exists outside the animation still require separate judgement.

The useful architectural point is simpler: accessibility behaviour should live with the interaction it modifies.

Passing data across the boundary should stay boring

Once the client island is small, its props tend to become clearer.

<AnimatedProductCard
  title={product.title}
  image={product.image}
  href={product.href}
/>

This is preferable to passing half a server-side application into a client animation component and asking it to reconstruct the page.

Next.js requires props crossing into Client Component entry points to be serializable.

For interaction work, that constraint can be productive.

Send the information the effect needs.

Keep database access, server-only secrets and unrelated application logic on the other side of the boundary.

The animation should rarely need to know how the product record was obtained.

It needs to know what it is animating.

A practical decision tree

When placing an animation in a Server Component architecture, I use roughly this sequence:

Can CSS express the behaviour?

Keep the React component on the server unless something else requires client code.
Does the effect require state, event handlers or a browser API?

Create a Client Component.
How small can that client boundary reasonably be?

Do not automatically promote the parent page or layout.
Can server-rendered content be passed through the interactive wrapper?

Prefer composition to moving data work into the client.
What happens before hydration?

The initial HTML should still produce a sensible interface.
What owns lifecycle and cleanup?

Observers, listeners, timelines and render loops need explicit teardown.
What happens on touch and reduced motion?

The desktop interaction is only one operating condition.

This model scales better than treating "use client" as a fix for animation errors.

Where source-first interaction patterns become useful

This boundary work is also why reusable interaction code is more useful when it arrives as something you can inspect rather than an opaque visual preset.

A polished interaction eventually collides with the application around it: the breakpoint changes, the scroll container is no longer window, the hero lives under a different stacking context, reduced motion needs another state, or an effect that makes sense with a mouse should disappear on touch.

Hyperiux Vault takes a source-first approach to React and Next.js interaction patterns: effects are added to the project as editable source, so the team can inspect and adapt the implementation rather than being limited to a runtime-only abstraction.

That matters particularly around Server Components because the correct client boundary is application-specific. An interaction can provide a useful starting architecture, but your route structure, content source and surrounding component tree still determine where that boundary should sit.

The useful thing to reuse is the interaction logic.

You should still own the architectural decision.

The boundary is part of the design

Server Components do not make animation awkward. They force a useful question that client-only React made easy to ignore.

Which part of this interface genuinely needs to stay alive in the browser?

Sometimes the answer is an entire interactive experience.

Sometimes it is a 40-line wrapper around server-rendered content.

Sometimes the answer is none of the React tree at all because CSS already does the job.

Next.js uses Server Components by default in the App Router and recommends Client Components where interaction or browser APIs require them. Animation architecture works best when it follows the same principle instead of treating movement as permission to move the whole page to the client.

Keep data and structure where the server is useful.

Put runtime behaviour where the browser is required.

And make the boundary follow the interaction rather than the screenshot.

Read to know, how to choose between declarative and imperative animation in React by looking at state ownership, sequencing, lifecycle, scroll choreography, and hybrid patterns.

Jyoti Pathak — Fri, 09 Oct 2026 09:11:12 +0000

Hyperiux

Oct 9

Declarative vs Imperative Animation in React: Where Each Model Wins

#react #animation #frontend #javascript

11 min read

[Boost]

Jyoti Pathak — Fri, 09 Oct 2026 09:08:29 +0000

Hyperiux

Oct 9

Declarative vs Imperative Animation in React: Where Each Model Wins

#react #animation #frontend #javascript

11 min read

How to Choose Between CSS, GSAP, Motion and Three.js for Website Animation

Jyoti Pathak — Wed, 07 Oct 2026 09:30:53 +0000

How to Choose Between CSS, GSAP, Motion and Three.js for Website Animation

A button changes color on hover. A card expands into a modal. A product story pins sections while images move through a sequence. A liquid surface reacts to the pointer.

Calling all four of these things “website animation” hides the decision that actually matters.

CSS, GSAP, Motion and Three.js can all participate in a website's motion system, but they operate at different layers. CSS is excellent when animation belongs to styling and interface state. Motion fits naturally when movement follows React state, layout or gestures. GSAP becomes attractive when timing and orchestration are the difficult parts. Three.js belongs to a different rendering model entirely: scenes, cameras, meshes, materials and shaders rather than ordinary DOM elements.

The useful question is therefore:

What kind of thing am I animating, and what is making the animation difficult?

That question usually narrows the choice quickly.

The short version

Choose	When the problem is mainly
CSS	States, hover/focus feedback, simple entrances and self-contained transitions
Motion	React state, component enter/exit, layout changes, gestures and UI-oriented motion
GSAP	Precise sequences, scroll choreography, timelines, SVG or imperative multi-element animation
Three.js	WebGL scenes, shaders, particles, 3D objects and graphics that should not be DOM elements

This is not a ladder from “basic” to “advanced.”

A well-built marketing page might use all four. Its buttons could use CSS, its mobile navigation could use Motion, its scroll narrative could use GSAP and its hero canvas could use Three.js.

The architecture should follow the interaction rather than forcing every effect through whichever package happens to be installed already.

Start with CSS more often than you think

Suppose a button needs to move upward by two pixels and change background color on hover.

Installing an animation library for that interaction does not make it more sophisticated. It gives a small state transition another runtime abstraction.

.button {
  transform: translateY(0);
  transition:
    transform 180ms ease,
    background-color 180ms ease;
}

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

CSS transitions are especially good when animation is a direct consequence of CSS state:

:hover
:focus-visible
:active
a class changing
a data attribute changing
a media query changing

Keyframe animations extend that model when the movement has intermediate states rather than a simple start and end.

@keyframes reveal {
  from {
    opacity: 0;
    transform: translateY(12px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Browsers already have substantial machinery for running these animations. The cost depends heavily on which properties are changing, not simply whether CSS or JavaScript initiated them.

That distinction matters.

“CSS is fast, JavaScript is slow” is too crude to be useful. Animating transform and opacity is very different from repeatedly forcing layout and paint work. A badly chosen CSS property can still produce a bad animation.

The native boundary keeps moving

Before reaching for a library, check what the platform can already express.

CSS scroll-driven animations can tie keyframe progress directly to a scroll or view timeline. The View Transitions API handles another class of state and page transitions natively, while the Web Animations API gives JavaScript direct control over browser animations without requiring a full animation library.

These APIs do not make Motion or GSAP obsolete. They move the point at which a dependency becomes justified.

A progress indicator linked directly to document scroll may no longer require scroll-event code. A tightly choreographed pinned product sequence with overlapping states still has a very different coordination problem.

Use the smallest mechanism that accurately describes the interaction.

CSS starts becoming awkward when state is no longer enough

Imagine a hero sequence with six elements:

the eyebrow appears;
the heading reveals;
two decorative lines extend;
the image begins moving before the heading finishes;
metadata follows 120ms later;
everything reverses differently when the section leaves.

You can encode that with delays and keyframes.

The uncomfortable part is maintaining the relationships.

Change the duration of the heading and you may need to recalculate several delays. Add another step and the sequence becomes a small scheduling system expressed through stylesheets.

Once the timing relationships become harder to maintain than the transforms themselves, a timeline starts earning its place.

Choose Motion when animation belongs to React state

Consider an accordion.

The user clicks a control, React state changes, the component changes size, surrounding content moves, an icon rotates and perhaps some content enters or exits.

This problem is mainly a relationship between component state and visual state.

That is where Motion tends to feel natural.

import { motion } from "motion/react";

function Panel({ open }) {
  return (
    <motion.div
      animate={{
        opacity: open ? 1 : 0.6,
        scale: open ? 1 : 0.98,
      }}
    />
  );
}

Motion provides React-oriented APIs for animation, gestures, scrolling and layout changes. Its layout system can animate changes in an element's position and size, while layoutId can connect visually related elements across states.

That makes it particularly useful for interactions such as:

accordions;
tabs;
modals;
drawers;
expanding cards;
sortable interfaces;
shared-element transitions;
components entering and leaving the tree;
drag interactions;
hover and tap behaviour tied to component state.

For React applications, the important advantage is conceptual.

Your animation often remains close to the state that caused it.

You are not asking an external timeline to observe that isOpen became true; the animated state can be expressed directly in the component.

Motion is particularly useful around layout

Layout animation is one of those jobs that sounds simple until you attempt it manually.

A card changes position because another card disappeared. The browser immediately knows the new layout, but visually connecting the previous geometry to the next geometry takes more work than adding a CSS transition to left and top.

Motion provides layout-specific APIs for that class of problem, including transform-based layout animation.

If your interface contains lots of movement caused by application state rather than authored timelines, this can remove a considerable amount of coordination code.

Motion can also handle scroll, sequences and gestures

Motion is not confined to small component transitions.

It supports scroll-triggered and scroll-linked animation, gestures such as hover, tap and drag, and animation sequences through its broader APIs.

This overlap is worth acknowledging because the boundaries between tools are not absolute. The question is which model most naturally describes the interaction.

If the animation reads as this component is now in this state, Motion usually gives you a vocabulary that fits the application.

Choose GSAP when choreography becomes the problem

Now consider a landing-page hero where:

text is split into lines;
lines reveal in sequence;
an image scales simultaneously;
a mask begins halfway through the image animation;
a decorative SVG path follows;
the sequence can be scrubbed or reversed;
a later section pins while several animations respond to scrolling.

At this point, the interesting object is the sequence itself.

GSAP is very good at making that sequence explicit.

const tl = gsap.timeline();

tl.from(".title", {
  yPercent: 100,
  duration: 0.8,
})
  .from(
    ".image",
    {
      scale: 1.15,
      duration: 1.2,
    },
    "<0.2"
  )
  .from(
    ".meta",
    {
      opacity: 0,
      y: 12,
    },
    "-=0.4"
  );

The exact syntax matters less than what it represents: relationships between animations are first-class.

GSAP's core exposes tweens and timelines, while its wider ecosystem covers scroll animation, SVG work, text, dragging, FLIP-style transitions and other interaction problems.

This is particularly comfortable when a designer is thinking in terms such as:

Start B shortly after A, let C overlap both, then reverse the sequence differently.

Trying to express that as a collection of independent component states can be more awkward than acknowledging that you have a timeline.

GSAP and React solve different layers

Using GSAP in React is not unusual, but the architectural relationship differs from Motion.

Motion extends React's declarative component model. GSAP is framework-agnostic and generally operates imperatively on animation targets.

In a React component, lifecycle deserves attention.

"use client";

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

gsap.registerPlugin(useGSAP);

export function Hero() {
  const root = useRef(null);

  useGSAP(
    () => {
      gsap.from(".hero-title", {
        y: 40,
        opacity: 0,
      });
    },
    { scope: root }
  );

  return (
    <section ref={root}>
      <h1 className="hero-title">Hello</h1>
    </section>
  );
}

GSAP recommends registering useGSAP, and the hook uses GSAP context to help scope animation work and clean it up with the component lifecycle.

In Next.js App Router projects, code using hooks and browser-side animation belongs on the client side, which is why the example includes "use client".

That boundary is easy to overlook in animation demos.

A demo has one mount.

An application has route changes, remounts, responsive conditions, state updates and development behaviour such as React Strict Mode. Animations that create listeners, triggers or imperative state need to disappear as carefully as they appeared.

Scroll-heavy work is a common reason to choose GSAP

ScrollTrigger changes the calculation for experiences where scroll itself becomes part of the choreography.

A simple fade when an element enters the viewport does not require that machinery. CSS, IntersectionObserver, Motion or another small mechanism may cover it cleanly.

A pinned sequence where five visual states overlap, scrub, reverse and respond to viewport changes is a different problem. There, combining scroll state with GSAP's timeline model can make the implementation easier to reason about.

Choosing GSAP because one heading needs to fade in is usually excessive. Choosing it because the page contains several tightly coordinated scroll sequences is much easier to justify.

Choose Three.js when the browser needs to render a scene

Three.js changes the comparison because it is primarily a rendering library, not another DOM animation abstraction.

CSS, Motion and GSAP commonly animate things the browser already rendered as HTML or SVG.

Three.js usually renders the visual itself.

You create objects, add them to a scene, position a camera and render the result through WebGL.

A minimal structure looks more like this:

import * as THREE from "three";

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(
  45,
  window.innerWidth / window.innerHeight,
  0.1,
  100
);

camera.position.z = 5;

const renderer = new THREE.WebGLRenderer({
  antialias: true,
});

renderer.setSize(window.innerWidth, window.innerHeight);

const geometry = new THREE.BoxGeometry(1, 1, 1);
const material = new THREE.MeshBasicMaterial();

const mesh = new THREE.Mesh(geometry, material);
scene.add(mesh);

renderer.setAnimationLoop(() => {
  mesh.rotation.y += 0.01;
  renderer.render(scene, camera);
});

Three.js recommends defining the animation loop with renderer.setAnimationLoop() rather than manually wiring requestAnimationFrame() because the renderer can manage the loop appropriately across supported rendering contexts.

This changes the engineering problem.

A DOM animation asks questions such as:

Which element should move, and when?

A Three.js implementation adds another set:

What should be rendered? What geometry and materials are involved? What resolution is the canvas? Which textures are loaded? Does the scene need another frame when nothing has changed?

Three.js makes sense for genuinely graphical problems

Examples include:

3D product viewers;
particle fields;
shader-driven backgrounds;
fluid or distortion effects;
spatial scenes;
3D typography;
image transitions implemented through textures;
surfaces that need per-pixel graphical effects.

A collection of pricing cards moving upward does not become better because each card is a plane inside WebGL.

Keeping semantic content in the DOM usually gives you simpler text rendering, accessibility, responsiveness and interaction behaviour.

Use Three.js when the visual idea actually benefits from graphics rendering.

GSAP, Motion and Three.js can work at different layers

“GSAP vs Three.js” often turns out to be the wrong comparison.

GSAP can animate numeric properties belonging to Three.js objects while Three.js remains responsible for rendering the scene.

gsap.to(mesh.rotation, {
  y: Math.PI * 2,
  duration: 2,
  ease: "power3.inOut",
});

Three.js renders the pixels.

GSAP controls how the values evolve over time.

That division of labour is useful when a graphical scene still needs authored choreography.

Motion can also participate in Three.js animation. Its current Three.js integration can animate objects, materials and shader uniforms, including alongside DOM animation sequences. Direct Three.js integration is part of Motion's Motion+ offering, so it should not be confused with the ordinary motion/react component workflow used earlier in this article.

The larger point remains the same: these tools are not four mutually exclusive choices.

They occupy overlapping layers.

A practical decision tree

Before installing anything, ask what drives the movement.

Is it mostly a style state?

Hover, focus, active state, a simple reveal or a contained decorative keyframe usually belongs in CSS.

Check native APIs before adding another dependency, particularly for straightforward scroll-linked or transition work.

Does movement closely follow React component state?

A modal mounting, an accordion changing height, cards reordering or a drag interaction points naturally toward Motion.

The component tree and visual state can remain closely connected.

Has timing become an authored system?

Once the implementation depends on overlapping sequences, coordinated SVG movement, multiple timelines or detailed scroll choreography, GSAP becomes easier to justify.

The timeline is now part of the design.

Does the effect require a graphics renderer?

Shaders, particle systems, 3D scenes and texture-based effects belong in Three.js territory.

Another animation system can still control values inside that scene.

Do not choose by demo smoothness

Animation demos run under suspiciously pleasant conditions.

There may be one effect on the page, no analytics, no application state, no route transition, no CMS content with unpredictable lengths and no low-powered phone trying to render the whole thing.

Production introduces different questions.

What properties are changing?

Performance depends on the work an animation creates.

A small animation library does not rescue an effect that repeatedly causes expensive layout. Nor is a CSS animation automatically cheap simply because JavaScript is absent.

Transforms and opacity often have a very different rendering profile from properties that repeatedly affect layout or expensive paint work.

Measure the actual page rather than treating the choice of API as a performance benchmark.

Does anything run continuously?

A button transition ends after 180ms.

Many animated Three.js scenes render continuously while active. Others can render only when something changes.

Those models have radically different budgets.

For a continuously rendered scene, ask whether it needs to remain active while offscreen, whether the tab is visible, what device-pixel ratio is being used, how expensive the shaders are, how large the textures are and whether post-processing is justified.

A smooth desktop demo does not answer those questions.

What happens on touch?

A magnetic cursor interaction built around precise mouse coordinates does not become mobile-friendly because its dimensions respond to the viewport.

Touch has a different input model.

Hover-only ideas need an alternate interaction or should disappear when they no longer have a job.

What happens with reduced motion?

prefers-reduced-motion should influence the interaction design, not merely reduce every duration from 0.8 to 0.4.

Sometimes the correct reduced-motion state is a simpler transition.

Sometimes it is an immediate state change.

Sometimes a decorative graphical scene should become a static frame.

Reduced motion is also only one part of accessibility. If animation belongs to a modal, menu, tabs or another interactive component, the static and animated states still need appropriate semantics, keyboard behaviour, focus handling and visible focus. Motion should not become responsible for hiding an interaction model that does not work without it.

Standardize responsibilities before APIs

Frontend teams like standardization because every additional dependency introduces another API, another upgrade path and another thing somebody needs to understand.

That instinct is healthy until a single animation tool is forced into jobs that another layer already handles better.

A sensible project might divide responsibility like this:

CSS
├── hover/focus feedback
├── simple transitions
└── low-level visual states

Motion
├── component enter/exit
├── layout changes
├── gestures
└── state-driven UI motion

GSAP
├── hero timeline
├── scroll storytelling
└── complex SVG sequence

Three.js
└── interactive WebGL hero

The useful standard is not “all animation uses Library X.”

It is knowing which layer owns which kind of movement.

Where source-first animation patterns can help

There is also a choice before the library choice: whether the interaction should be built from zero at all.

A complicated cursor, text treatment, page transition or WebGL effect often contains more production decisions than its visual idea suggests. Resize handling, pointer behaviour, cleanup, breakpoints, reduced-motion states and rendering constraints can surround the relatively small piece of code that creates the visible effect.

Hyperiux Vault takes a source-first approach to this problem for React and Next.js projects. Interaction patterns are added as editable source, so the implementation can be inspected and adapted inside the project rather than treated as a black-box animation runtime.

That matters most when the starting point is close to what you need but production conditions are different. The breakpoint may need to move. GSAP timing may need to match an existing motion system. A Three.js scene may need a cheaper mobile path. A cursor effect may need to disappear on touch.

The animation engine remains whichever engine makes sense for the effect. Vault's role is different: you begin with the interaction already expressed in code, then change the implementation where the project requires it.

If that workflow fits the project, browse Hyperiux Vault's interaction patterns and inspect the source approach before rebuilding the effect from a blank component.

A practical rule for each tool

If you need a rule you can remember during implementation:

Use CSS while the animation is primarily a styling or browser-state problem.

Use Motion when movement primarily follows React state, layout and gestures.

Use GSAP when timing, sequencing and choreography have become the system you need to manage.

Use Three.js when the visual needs a graphics renderer rather than another DOM animation API.

There will be exceptions. That is fine.

The mistake is treating animation complexity as a prestige scale where CSS is the beginner option and WebGL is the advanced one.

A two-property CSS transition can be exactly the right implementation. A shader-powered hero can also be exactly right.

The quality of the decision comes from matching the mechanism to the interaction.

How to Add Award-Winning Website Interactions to React Without Building Every Effect From Scratch

Jyoti Pathak — Mon, 05 Oct 2026 14:35:10 +0000

How to Add Award-Winning Website Interactions to React Without Building Every Effect From Scratch

A surprising number of “award-site” interactions are difficult for reasons that have little to do with the visible transform.

Moving a heading upward is easy. The real work appears around it: deciding when the sequence starts, coordinating it with nearby elements, handling resize, cleaning up listeners or timelines, adapting pointer behaviour for touch, respecting reduced motion, and making sure a Next.js route does not inherit animation state from a component that no longer exists.

Building all of that from scratch for every section is rarely a good use of creative frontend time.

A more practical approach is to separate three decisions:

Use CSS for interaction that does not need application state or continuous measurement.
Use an animation or rendering tool when the behaviour actually requires one.
Reuse existing interaction machinery when the interesting part of the work is adaptation, not invention.

Then spend bespoke engineering on the moments that make the site recognisably yours.

Start with the job of the interaction

Before choosing GSAP, Motion, Three.js or anything else, decide what changes for the user when the interface moves.

A useful interaction might acknowledge input, control reading order, preserve context while evidence changes, show how two states relate, or create one deliberately high-attention brand moment.

Those are different jobs, and they deserve different levels of technical effort.

A practical way to think about them is:

Interaction level	Typical job	Examples
Functional	Explain state or acknowledge input	Button feedback, tabs, accordion, modal
Narrative	Control how content unfolds	Text reveal, sticky feature story, image transition
Signature	Create a distinctive product or brand moment	Spatial gallery, unusual hero, generative canvas, WebGL treatment

Most pages need many functional interactions, a smaller number of narrative ones, and perhaps one signature interaction.

The imbalance usually appears when everything is promoted to the third category. The eyebrow fades, the heading splits into words, the cards stagger, the screenshot scales, the background drifts and the cursor changes shape inside the same viewport. Nothing is technically broken. Motion has simply removed the hierarchy.

Reuse the interaction primitive, not the finished design

Suppose a designer gives you this feature section:

Keep the product screenshot pinned while three claims move through the left column. Each claim should bring a different part of the screenshot into focus.

The distinctive part is the relationship between the claims and the product.

A large amount of the implementation around that idea is less distinctive:

measuring the section;
deciding when it becomes active;
tracking progress;
coordinating the sticky state;
cleaning up;
dealing with resizing;
reducing the behaviour on smaller screens;
providing a readable reduced-motion state.

You can build all of that again. You can also start with a working sticky/scroll interaction and spend more time deciding how this particular product should behave inside it.

This is where reusable interaction primitives become useful.

A primitive is not a finished aesthetic. It supplies enough behaviour to avoid rebuilding the same machinery while leaving the design decisions exposed.

For example:

<Reveal
  trigger="viewport"
  distance={24}
  duration={0.7}
>
  <FeatureGrid />
</Reveal>

or:

<ScrollSequence>
  <StickyMedia />
  <FeatureSteps />
</ScrollSequence>

Your project still decides the typography, hierarchy, timing, visual treatment, breakpoints, content and fallback.

The reusable part is infrastructure. The authorship is in what you do with it.

Use CSS when CSS already solves the problem

Creative frontend becomes unnecessarily complicated when JavaScript is treated as the entrance fee for interesting motion.

CSS is often enough for:

hover feedback;
button fills;
simple transforms;
masks and clipping;
decorative loops;
focus states;
uncomplicated entrances;
colour and underline transitions.

A button fill, for example, needs very little machinery:

<button className="fillButton">
  <span>View project</span>
</button>

.fillButton {
  position: relative;
  overflow: hidden;
  isolation: isolate;
  border: 1px solid currentColor;
  padding: 0.75rem 1rem;
  background: transparent;
  color: #111;
  cursor: pointer;
}

.fillButton::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  background: #111;
  transform: translateY(101%);
  transition: transform 500ms cubic-bezier(.22, 1, .36, 1);
}

.fillButton > span {
  position: relative;
}

.fillButton:hover::before,
.fillButton:focus-visible::before {
  transform: translateY(0);
}

.fillButton:hover,
.fillButton:focus-visible {
  color: #fff;
}

@media (prefers-reduced-motion: reduce) {
  .fillButton::before {
    transition-duration: 0.01ms;
  }
}

There is no timeline to initialise, no component state to synchronise and no resize work.

The :focus-visible state also matters. An interaction that communicates affordance only when a mouse happens to be above it has confused an input method with a user requirement.

Use Motion when animation belongs naturally to component state, layout or gestures

Motion fits particularly well when movement is already close to the React component model: entering and leaving UI, layout changes, drag or press states, viewport-triggered reveals, and scroll-linked values.

A reusable reveal can stay fairly small:

"use client";

import { motion, useReducedMotion } from "motion/react";
import type { ReactNode } from "react";

type RevealProps = {
  children: ReactNode;
  delay?: number;
};

export function Reveal({
  children,
  delay = 0,
}: RevealProps) {
  const shouldReduceMotion = useReducedMotion();

  return (
    <motion.div
      initial={
        shouldReduceMotion
          ? { opacity: 1 }
          : { opacity: 0, y: 24 }
      }
      whileInView={{
        opacity: 1,
        y: 0,
      }}
      viewport={{
        once: true,
        amount: 0.25,
      }}
      transition={{
        duration: shouldReduceMotion ? 0 : 0.7,
        delay: shouldReduceMotion ? 0 : delay,
        ease: [0.22, 1, 0.36, 1],
      }}
    >
      {children}
    </motion.div>
  );
}

Motion currently supports viewport-triggered behaviour through whileInView, scroll-linked values through APIs such as useScroll, layout animation, and gesture states including hover, tap and focus.

The code above is deliberately modest. That is useful.

A generic reveal should not become the visual protagonist of the page. Its job is to establish reading order and then get out of the way.

Use GSAP when choreography becomes the problem

Some interactions stop being individual state changes and become sequences.

The title arrives. The supporting copy overlaps its final 300 milliseconds. The media starts slightly before the copy finishes. A later section pins to the viewport, advances with scroll progress, and needs to revert correctly when the component unmounts.

Timeline-oriented control is valuable here.

With React, lifecycle matters as much as sequencing. The official @gsap/react integration provides useGSAP(), scoped contexts and cleanup behaviour; GSAP's current guidance also recommends registering the hook as a plugin.

"use client";

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

gsap.registerPlugin(useGSAP);

export function Hero() {
  const root = useRef<HTMLElement>(null);

  useGSAP(
    () => {
      const timeline = gsap.timeline();

      timeline
        .from(".hero-title", {
          yPercent: 100,
          duration: 0.8,
          ease: "power3.out",
        })
        .from(
          ".hero-copy",
          {
            opacity: 0,
            y: 24,
            duration: 0.6,
            ease: "power2.out",
          },
          "-=0.35"
        );
    },
    { scope: root }
  );

  return (
    <section ref={root}>
      <div className="hero-title-mask">
        <h1 className="hero-title">
          Build the memorable part.
        </h1>
      </div>

      <p className="hero-copy">
        Reuse the machinery around it.
      </p>
    </section>
  );
}

.hero-title-mask {
  overflow: hidden;
}

Scoping the timeline to root prevents those class selectors from becoming accidental global animation targets. useGSAP() also records GSAP work in its context so it can be reverted when the component is torn down.

If an event handler creates additional GSAP work later, treat that lifecycle separately rather than assuming everything created after the initial hook is automatically covered.

In Next.js, decide the client boundary before the animation API

A motion-heavy component often depends on things the server cannot provide: pointer coordinates, window, layout measurements, canvas, WebGL or browser observers.

That is an architectural condition, not a reason to turn an entire page into a client component.

Keep the static content and layout server-rendered where it makes sense, then isolate the interaction behind the smallest useful client boundary:

// app/product/page.tsx
import { InteractiveHero } from "@/components/interactive-hero";

export default function ProductPage() {
  return (
    <main>
      <InteractiveHero />
      <ProductDetails />
    </main>
  );
}

// components/interactive-hero.tsx
"use client";

export function InteractiveHero() {
  // Browser-dependent animation logic lives here.
  return <section>{/* ... */}</section>;
}

For particularly browser-bound experiences such as WebGL scenes, a dynamic client-only import can also be appropriate when server rendering provides no useful output.

The exact boundary depends on the effect. The useful rule is narrower: do not widen the client surface merely because one part of a section moves.

This also gives hydration failures fewer places to hide.

Vault's current installation guidance applies the same principle to effects that depend on scroll position, pointer movement, layout measurement, animation timelines, canvas or WebGL.

Treat WebGL as an escalation

Three.js and React Three Fiber are justified when the visual model needs something the DOM is poor at producing: depth, custom shaders, particle systems, image displacement, lighting, spatial scenes or other GPU-driven rendering.

They are less convincing when the requirement is “make the hero feel expensive.”

As a complexity heuristic, start with the simplest rendering layer that can express the idea. A DOM treatment may be enough. Canvas becomes useful for different workloads. WebGL earns its place when the experience needs the rendering model it provides.

The important production questions also change once a scene renders continuously:

What happens to the render loop when the scene is off-screen?
How high can the device pixel ratio go?
What changes on a weaker phone?
How expensive are textures, shaders and post-processing passes?
Does reduced motion remove movement or provide a static alternative?

A WebGL scene can be technically impressive and still be the wrong interaction for a pricing page whose main job is comparison.

One section, three implementation decisions

Consider a common product-story section:

Desktop behaviour

A product image remains pinned on the right. Three claims move through the left column. As each claim becomes active, the image changes emphasis to match it.

There are at least three different pieces of interaction inside that one idea.

1. The claim entrance

A subtle opacity/position reveal does not need a custom timeline. Motion's viewport behaviour or even CSS plus an observer is enough.

2. The pinned claim-to-image sequence

This is where the state relationship matters. The active claim must stay synchronised with the media, and the section may need scroll progress or a timeline. GSAP/ScrollTrigger, Motion scroll values or an existing scroll primitive can all be reasonable depending on the exact choreography.

The choice should follow the behaviour, not a rule that “award sites use GSAP.”

3. The mobile version

A 390px-wide screen does not need a miniature sticky desktop composition.

Stack the claim beside its corresponding image. Preserve the claim/evidence relationship and remove the mechanism that was only useful because desktop had room for two persistent columns.

The reduced-motion version can make the same move. Show each claim with its evidence in a stable reading sequence rather than forcing the user through a scrubbed transition.

That is the larger pattern: reuse does not remove design decisions. It moves your engineering time toward the decisions that survive across contexts.

Source-first interaction components make more sense once the demo stops matching the product

A reusable interaction becomes much more interesting when its implementation is editable.

The demo's breakpoint will eventually be wrong for your layout.

Its easing may feel too soft beside the rest of your interface.

The hero might sit inside a different stacking context. Your typeface may wrap the animated heading into three lines instead of two. A pointer effect that looks good with a mouse may need an entirely different touch treatment.

At that point, an API with twenty configuration props and source code you can directly modify are different kinds of convenience.

Source-first interaction components let the effect become normal project code:

components/
  interactions/
    sticky-feature/
      StickyFeature.tsx
      useStickyFeature.ts
      styles.css

You can inspect the listener setup, change the DOM structure, alter a breakpoint, simplify the mobile path, remove a dependency or replace part of the implementation when the effect allows it.

The abstraction gets you to a working behaviour. It does not have to remain intact forever.

This is the model behind Hyperiux Vault

This is also the workflow we are building around Hyperiux Vault.

Vault is a library of creative interaction patterns for React and Next.js. The current catalogue spans areas including text animation, backgrounds, buttons, carousels, scroll interactions, navigation, cursor effects, loaders, page transitions and WebGL. Different effects can use different tools rather than forcing the entire catalogue through one animation engine.

The important part for this argument is how the effects enter the project.

Vault uses a source-first workflow: the selected effect is added as editable project files, with effect-specific dependencies made visible rather than hidden behind one large interaction runtime.

The expected workflow is:

Preview a behaviour that solves the interaction job.
Add the relevant source.
Read the implementation.
Remove or alter what your page does not need.
Tune the behaviour until it belongs to the product.
Test it under the conditions the original demo could not know about.

That last part is where most of the real work lives.

A reusable interaction should save you from rebuilding solved machinery. It should not decide the art direction for you.

Customise the variables people actually perceive

Changing the accent colour does not make a reused interaction feel native to the site.

The more meaningful variables are usually behavioural.

Timing and easing change weight. A short response with a direct easing curve feels different from a long, heavily eased entrance even when both travel the same distance.

Distance and scale change visual force. Moving 12 pixels establishes hierarchy. Moving an entire viewport turns the transition into an event.

Trigger position changes pacing. An entrance that starts as soon as an element touches the viewport has a different reading rhythm from one that waits until the section is established.

Typography changes animation geometry. A split-text effect that looked clean in the demo can fall apart once another font, line height or responsive measure creates different wrapping.

Input and breakpoint behaviour decide whether the interaction still has a job. Pointer attraction does not become a mobile interaction simply because the viewport is narrower.

These choices are good candidates for shared project-level motion values:

export const motionTokens = {
  duration: {
    quick: 0.2,
    standard: 0.5,
    expressive: 0.9,
  },
  easing: {
    standard: [0.22, 1, 0.36, 1],
    soft: [0.16, 1, 0.3, 1],
  },
  distance: {
    subtle: 12,
    standard: 24,
    large: 48,
  },
} as const;

Not every effect should use the same duration. The point is to create a vocabulary narrow enough that unrelated interactions still appear to belong to the same product.

Performance belongs in the interaction decision

Creative frontend work becomes difficult to optimise when performance review begins after the interaction is already considered finished.

Ask about cost while choosing the behaviour.

A DOM reveal that changes transform and opacity has a very different workload from a scroll handler that repeatedly measures layout. A cursor effect that creates work for every pointer event deserves different scrutiny from a CSS hover transition. A WebGL scene that renders every frame keeps spending resources even when nothing obvious changes.

Useful production questions include:

Does anything continue running off-screen?
Are scroll and pointer listeners cleaned up?
Is layout being read repeatedly during animation?
Can event work be coalesced into the render loop rather than triggering uncontrolled updates?
Can mobile reduce the amount of work rather than merely shrink the layout?
Does a continuously rendered canvas need the device's full pixel ratio?
Can decorative assets or heavy rendering load after critical content?
What remains when animation is removed?

There is no universal rule that the least visually complex effect is always the cheapest. Measure the implementation you actually ship.

Reduced motion is one requirement, not the accessibility strategy

Respecting prefers-reduced-motion is part of responsible motion design, and the browser exposes that preference specifically so interfaces can reduce or replace non-essential motion. It does not solve every accessibility problem by itself.

A production interaction also needs questions such as:

Can the control be reached with a keyboard?
Is the focus state visible?
Does a hover effect have another input path?
Does removing animation hide information or make state changes ambiguous?
Is the static DOM still semantic?
Can touch users perform the action without precise pointer coordinates?
If content enters through animation, is it still readable when the animation system fails?

For a cursor trail, reduced motion may mean disabling the trail. For a route transition, it may mean using a near-instant state change. For a product explanation whose animation carries meaning, it may require a different static layout rather than simply setting every duration to zero.

Accessibility changes the design of the fallback, not just the speed of the tween.

Do not animate every element that enters the viewport

The most reusable animation pattern in frontend development may also be the easiest to overuse:

element enters viewport
↓
opacity 0 → 1
translateY 24px → 0

Apply that to a few important transitions and it can help establish order.

Apply it to every heading, paragraph, card, logo and footer link and the page starts acknowledging the existence of its own DOM.

A better page has contrast.

The hero can carry a more expressive entrance. Narrative sections can reveal content where sequence matters. Dense product information can remain stable. Buttons can respond quickly to input. One signature section can consume more of the interaction budget.

And the footer can remain a footer.

Stillness is part of the motion system.

Build from scratch where originality has leverage

Reusable interaction primitives should not replace custom creative development.

Build the interaction specifically for the project when the behaviour itself carries the idea: a product needs an unusual manipulation model, the brand concept depends on custom rendering, existing primitives keep fighting the desired composition, or the interaction will become a recognisable part of the product.

Those are good places to spend bespoke engineering time.

Rebuilding yet another viewport observer, split-text wrapper or basic magnetic button has less leverage if a maintainable implementation already exists and can be adapted.

This is the trade-off worth protecting:

reuse the solved infrastructure so custom effort can go somewhere users will actually notice.

A practical workflow

When adding high-end interaction to an existing React or Next.js site, I would work in roughly this order:

Make the static design work first. Motion will not repair weak hierarchy, spacing or typography.
Identify the high-attention moments. The hero, product explanation or major transition usually deserves more budget than supporting content.
Write down each interaction's job. “Connect these two product states” leads to better implementation decisions than “add animation.”
Look for an existing primitive before building infrastructure.
Inspect the implementation before adopting it. Check dependencies, listeners, observers, lifecycle, rendering method and browser assumptions.
Choose the client boundary deliberately in Next.js.
Remove capability the page does not need.
Apply the project's timing, spacing, type and breakpoint logic.
Design touch, keyboard and reduced-motion behaviour rather than treating them as post-processing.
Test the composition on real devices.
Remove the weakest effect.

The last step sounds flippant until you try it.

Two individually excellent interactions can compete when they share the same page. Removing one often gives the other enough visual space to become the memorable moment.

A better test for “custom”

Developers sometimes use custom as a statement about where the code originated.

Users cannot see your Git history.

They experience whether the response feels immediate, whether the sequence is easy to follow, whether movement belongs to the visual language, and whether the interaction survives the device they happen to be using.

A bespoke experience can start from bespoke code.

It can also start from an existing interaction whose timing, structure, input behaviour and fallback have been changed until they fit the product around it.

The test is not whether every line began with an empty file.

It is whether the interaction still looks borrowed when the work is finished.

Final thought

Award-winning website interaction does not require turning every React page into an animation research project.

Use CSS when the browser already has the mechanism. Use Motion when component state, gestures, layout or scroll fit its model. Use GSAP when sequencing and choreography demand tighter control. Escalate to Canvas or WebGL when the visual idea requires another rendering layer. Reuse interaction source where rebuilding the surrounding machinery adds little creative value.

Then spend the saved effort on the parts where judgement still matters: pacing, hierarchy, fallback behaviour, responsive adaptation and the one moment the page should genuinely own.

The page does not need to move more.

It needs better reasons to move.

I work on Hyperiux Vault, where we're building source-first interaction patterns for React and Next.js. The product is based on the same premise described here: start from editable interaction machinery, then adapt it until it belongs to the project rather than the demo.

For creative React work, where do you draw the line between a reusable interaction primitive and something worth building from scratch?

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.

DEV Community: Jyoti Pathak

Why Your React Animations Feel Slow Even at 60 FPS

Why Your React Animations Feel Slow Even at 60 FPS

60 FPS Is a Target, Not a Diagnosis

Your Browser Has More Work to Do Than Draw the Animation

React Can Make the Animation Compete With Your Application

requestAnimationFrame() Does Not Make Expensive Work Cheap

Sometimes the Performance Problem Is Actually a Motion Problem

Input-Coupled Motion Exposes Latency Faster

“Use Transform and Opacity” Is Good Advice With Missing Footnotes

Profile Frame Time, Not Just the Counter

Test the Page, Not the Demo

Source Access Is Useful Because Performance Decisions Are Contextual

A Better Way to Debug “Slow” Animation

How to Keep Client-Side Animation From Taking Over Your Next.js Architecture

How to Keep Client-Side Animation From Taking Over Your Next.js Architecture

The problem is boundary creep

Keep "use client" as low as practical

Server-rendered content can still pass through a client wrapper

Before adding an animation library, ask whether CSS is enough

Motion does not require client ownership of the whole section

Imperative animation needs a clear owner

Do not make the animation timeline your page structure

WebGL and Canvas deserve their own island

ssr: false is useful, but it is not an architecture

Lazy loading and disabling SSR solve different problems

Keep global animation providers smaller than you think

Pause work the user cannot see

A practical architecture checklist

How source-first effects help with this

The goal is not zero client JavaScript

Why Some SaaS Websites Feel Custom Even When They Use Familiar UI Patterns

Visual customization only gets you so far

Start with the job of the interaction

Interaction can explain things screenshots cannot

Build a small interaction vocabulary

Pick a few places where interaction actually matters

The hero

The core product story

Navigation

Important feedback states

Not every section needs motion

Reusable interaction does not have to look reusable

React and Next.js implementation still need boundaries

Mobile should preserve the idea, not necessarily the effect

Reduced motion is part of the interaction system

Performance should influence the interaction choice

The most useful test is surprisingly simple

Custom-built is a result of decisions, not novelty

Server Components and Interactive UI: Where Animation Actually Belongs

Server Components and Interactive UI: Where Animation Actually Belongs

Animation does not automatically mean "use client"

The client boundary starts where runtime knowledge starts

"use client" is a module boundary, not an animation annotation

Server Components can still provide the animated content

Animation libraries make boundary placement easier to get wrong

Hydration is part of the animation

Scroll animation is mostly a browser problem

Route transitions are a different problem again

Browser input should influence the implementation

Reduced motion belongs at the same boundary

Passing data across the boundary should stay boring

A practical decision tree

Where source-first interaction patterns become useful

The boundary is part of the design

Read to know, how to choose between declarative and imperative animation in React by looking at state ownership, sequencing, lifecycle, scroll choreography, and hybrid patterns.

Declarative vs Imperative Animation in React: Where Each Model Wins

[Boost]

Declarative vs Imperative Animation in React: Where Each Model Wins

How to Choose Between CSS, GSAP, Motion and Three.js for Website Animation

How to Choose Between CSS, GSAP, Motion and Three.js for Website Animation

The short version

Start with CSS more often than you think

The native boundary keeps moving

CSS starts becoming awkward when state is no longer enough

Choose Motion when animation belongs to React state

Motion is particularly useful around layout

Motion can also handle scroll, sequences and gestures

Choose GSAP when choreography becomes the problem

GSAP and React solve different layers

`requestAnimationFrame()` Does Not Make Expensive Work Cheap

Keep `"use client"` as low as practical

`ssr: false` is useful, but it is not an architecture

Animation does not automatically mean `"use client"`

`"use client"` is a module boundary, not an animation annotation

`"use client"` describes a boundary

`ssr: false` solves a different problem

A practical test before adding `"use client"`