React Three Fiber Animation: When to Use useFrame, GSAP, or Springs

React Three Fiber gives you several credible ways to animate a scene. The difficult part is deciding who owns time.

Use useFrame when motion is continuous and belongs to each rendered frame. Use GSAP when the interaction depends on authored sequencing, easing, and playhead control. Use @react-spring/three when application state defines a changing destination and the animation should fluidly follow it.

The useful question is who should own time for this property?

A spinning model, a six-beat product reveal, and a hover scale can all appear inside the same <Canvas>. They still represent different timing problems. Treating them as one problem usually produces either an overbuilt render-loop callback or several animation systems competing over the same transforms.

A useful architecture is:

React intent → animation owner → Three.js object → R3F render

React owns durable application intent. The animation system decides how transient values move through time. Three.js objects receive those values. React Three Fiber renders the scene.

R3F already owns scene rendering

React Three Fiber is a React renderer for Three.js. It does not require React state to carry every intermediate transform in an animation.

Its useFrame hook executes a callback inside the shared render loop just before a frame is rendered. The hook also receives the frame delta, expressed in seconds. R3F’s documentation explicitly cautions against calling React setState inside that hot path.

A basic rotating mesh is enough to see the boundary:

1import { useRef } from "react";2import { useFrame } from "@react-three/fiber";3import type { Mesh } from "three";4 5export function Spinner() {6  const mesh = useRef<Mesh>(null);7 8  useFrame((_, delta) => {9    if (!mesh.current) return;10 11    mesh.current.rotation.y += delta * 0.8;12  });13 14  return (15    <mesh ref={mesh}>16      <boxGeometry />17      <meshStandardMaterial />18    </mesh>19  );20}

React declares the mesh, geometry and material. R3F advances the frame callback. The callback mutates a transient scene value directly.

React state should describe intent, not transport every frame

Suppose the model can be selected:

1const [selected, setSelected] = useState(false);

That is durable application state. Other components may care about it. The value may change content, controls, analytics or accessibility behavior.

This is a different category:

1useFrame(() => {2  setRotation((rotation) => rotation + 0.01);3});

Now React is carrying a high-frequency animation value through component state. R3F’s guidance instead puts transient frame updates in useFrame, generally through refs and direct object mutation.

React can decide what the interaction means. It does not need to narrate every intermediate transform.

useFrame: when motion belongs to the frame

useFrame is the clearest default when a value is procedural rather than authored.

A camera easing toward pointer input is one example. A shader timer is another. Continuous model rotation, damping, particle updates and simulation-style behavior fit the same class.

Consider pointer following:

1import { useRef } from "react";2import { useFrame, useThree } from "@react-three/fiber";3import type { Mesh } from "three";4 5export function PointerFollower() {6  const mesh = useRef<Mesh>(null);7  const pointer = useThree((state) => state.pointer);8 9  useFrame((_, delta) => {10    if (!mesh.current) return;11 12    const smoothing = 1 - Math.exp(-8 * delta);13    const targetX = pointer.x * 2;14    const targetY = pointer.y * 1.2;15 16    mesh.current.position.x +=17      (targetX - mesh.current.position.x) * smoothing;18 19    mesh.current.position.y +=20      (targetY - mesh.current.position.y) * smoothing;21  });22 23  return (24    <mesh ref={mesh}>25      <sphereGeometry args={[0.6, 32, 32]} />26      <meshStandardMaterial />27    </mesh>28  );29}

R3F pointer values are normalized coordinates. Multiplying them by 2 or 1.2 here is an interaction decision, not a universal conversion to Three.js world space. The camera and viewport determine what world-space mapping makes sense for a particular scene.

The architecture is the important part: the destination changes continuously, so the motion is evaluated continuously.

A complete shader-time example

A shader timer needs more context than a dangling material.current.uniforms reference. Here is the full boundary:

1import { useMemo, useRef } from "react";2import { useFrame } from "@react-three/fiber";3import {4  ShaderMaterial,5  type IUniform,6} from "three";7 8const vertexShader = `9  varying vec2 vUv;10 11  void main() {12    vUv = uv;13    gl_Position = projectionMatrix * modelViewMatrix14      * vec4(position, 1.0);15  }16`;17 18const fragmentShader = `19  uniform float uTime;20  varying vec2 vUv;21 22  void main() {23    float pulse = 0.5 + 0.5 * sin(uTime * 2.0);24    gl_FragColor = vec4(vUv.x, pulse, vUv.y, 1.0);25  }26`;27 28export function AnimatedShaderPlane() {29  const material = useRef<ShaderMaterial>(null);30  const elapsed = useRef(0);31 32  const uniforms = useMemo<Record<string, IUniform>>(33    () => ({34      uTime: { value: 0 },35    }),36    []37  );38 39  useFrame((_, delta) => {40    elapsed.current += delta;41 42    if (material.current) {43      material.current.uniforms.uTime.value = elapsed.current;44    }45  });46 47  return (48    <mesh>49      <planeGeometry args={[2, 2]} />50      <shaderMaterial51        ref={material}52        uniforms={uniforms}53        vertexShader={vertexShader}54        fragmentShader={fragmentShader}55      />56    </mesh>57  );58}

The timer is frame-owned. React does not need to rerender when uTime changes.

Where useFrame earns its place

Use it for work that naturally answers the question:

What should this value be on this frame?

That commonly includes continuous rotation, pointer following, damping, camera drift, shader uniforms and procedural simulation.Its advantage is architectural clarity, not an automatic performance win.

A useFrame callback can still allocate too much, run expensive calculations, keep unnecessary rendering alive or perform work better moved elsewhere.The hook gives frame work the correct home. It does not make frame work free.

GSAP: when motion belongs to a sequence

Now imagine a product hero with a designed entrance.The camera starts first. The product rotates before the camera finishes. A light intensifies. The object settles. During iteration, the sequence needs to pause, replay and reverse.The difficult part is no longer calculating a frame.It is coordinating time.

GSAP maintains an animation-frame-driven ticker that advances its global timeline, and its Timeline API supplies playhead and sequencing control for groups of tweens.

1"use client";2 3import { useLayoutEffect, useRef } from "react";4import { gsap } from "gsap";5import type { Group } from "three";6 7export function ProductIntro() {8  const group = useRef<Group>(null);9 10  useLayoutEffect(() => {11    if (!group.current) return;12 13    const timeline = gsap.timeline();14 15    timeline16      .fromTo(17        group.current.position,18        { z: -3 },19        {20          z: 0,21          duration: 1.2,22          ease: "power3.out",23        }24      )25      .fromTo(26        group.current.rotation,27        { y: -0.7 },28        {29          y: 0,30          duration: 1,31          ease: "power2.out",32        },33        "<0.2"34      );35 36    return () => {37      timeline.kill();38    };39  }, []);40 41  return (42    <group ref={group}>43      <mesh>44        <boxGeometry />45        <meshStandardMaterial />46      </mesh>47    </group>48  );49}

GSAP documents kill() as removing a timeline from its parent and stopping it, which makes lifecycle cleanup explicit when the React component unmounts.

The value here is not merely that GSAP can mutate a Three.js vector. The timeline owns the relationship between authored moments.

GSAP’s ticker and R3F’s renderer have different jobs

GSAP’s ticker advances GSAP animation time.R3F renders the Three.js scene.Those are different responsibilities.

Having two RAF-backed systems present does not by itself mean the WebGL scene is rendered twice. GSAP may update object values while R3F performs the actual scene render through its own frame scheduling.

The production question is: “Which system owns this property, and which system owns the scene render?”

React Spring: when motion belongs to a changing destination

Springs solve a different problem again. An object is inactive, then active. A card is unselected, then selected. A model is resting, then hovered. Before it reaches the destination, the target changes again.

React Spring is useful here because the meaningful input is the destination. The spring owns interpolation toward that target.

For React Three Fiber, the official integration is @react-spring/three. Its documentation uses animated scene elements and shows spring values updating Three.js properties without requiring a React render for each intermediate animation value.

1import { useState } from "react";2import {3  animated,4  useSpring,5} from "@react-spring/three";6 7export function SelectableMesh() {8  const [selected, setSelected] = useState(false);9 10  const springs = useSpring({11    scale: selected ? 1.2 : 1,12    position: selected13      ? ([0, 0.25, 0] as const)14      : ([0, 0, 0] as const),15  });16 17  return (18    <animated.mesh19      scale={springs.scale}20      position={springs.position}21      onClick={() => setSelected((value) => !value)}22    >23      <boxGeometry />24      <meshStandardMaterial />25    </animated.mesh>26  );27}

React owns selected. The spring owns the movement toward the resulting position and scale. “Declarative” here describes the relationship between state and destination. It does not mean React becomes the frame engine.

Runnable comparison: one visual, three animation owners

The cleanest way to compare the models is to keep the visual subject constant and change the timing requirement.

The following client component creates one R3F scene with three selectable modes:

• Frame: the mesh continuously follows pointer input using useFrame.
• GSAP: the mesh runs a replayable and reversible entrance timeline.
• Spring: clicking repeatedly changes a spring destination, including while the previous transition is still moving.

Only the active mode is mounted, so inactive systems cannot write to the same mesh property.

1"use client";2 3import {4  useLayoutEffect,5  useRef,6  useState,7} from "react";8import {9  Canvas,10  useFrame,11  useThree,12} from "@react-three/fiber";13import {14  animated,15  useSpring,16} from "@react-spring/three";17import { gsap } from "gsap";18import type { Mesh } from "three";19 20type Mode = "frame" | "gsap" | "spring";21 22export default function AnimationOwnershipDemo() {23  const [mode, setMode] = useState<Mode>("frame");24 25  return (26    <div>27      <div28        role="group"29        aria-label="Animation owner"30      >31        <button32          type="button"33          aria-pressed={mode === "frame"}34          onClick={() => setMode("frame")}35        >36          useFrame37        </button>38 39        <button40          type="button"41          aria-pressed={mode === "gsap"}42          onClick={() => setMode("gsap")}43        >44          GSAP45        </button>46 47        <button48          type="button"49          aria-pressed={mode === "spring"}50          onClick={() => setMode("spring")}51        >52          Spring53        </button>54      </div>55 56      <Canvas57        camera={{58          position: [0, 0, 5],59          fov: 45,60        }}61      >62        <ambientLight intensity={1.2} />63        <directionalLight64          position={[3, 4, 5]}65          intensity={2}66        />67 68        {mode === "frame" && <FrameMode />}69        {mode === "gsap" && <GsapMode />}70        {mode === "spring" && <SpringMode />}71      </Canvas>72    </div>73  );74}75 76function SharedGeometry() {77  return (78    <>79      <torusKnotGeometry80        args={[0.85, 0.28, 128, 24]}81      />82      <meshStandardMaterial83        roughness={0.3}84        metalness={0.15}85      />86    </>87  );88}89 90function FrameMode() {91  const mesh = useRef<Mesh>(null);92  const pointer = useThree((state) => state.pointer);93 94  useFrame((_, delta) => {95    if (!mesh.current) return;96 97    const smoothing = 1 - Math.exp(-7 * delta);98 99    mesh.current.position.x +=100      (pointer.x * 1.4 -101        mesh.current.position.x) *102      smoothing;103 104    mesh.current.position.y +=105      (pointer.y * 0.8 -106        mesh.current.position.y) *107      smoothing;108 109    mesh.current.rotation.y += delta * 0.6;110  });111 112  return (113    <mesh ref={mesh}>114      <SharedGeometry />115    </mesh>116  );117}118 119function GsapMode() {120  const mesh = useRef<Mesh>(null);121  const timeline = useRef<gsap.core.Timeline | null>(122    null123  );124 125  useLayoutEffect(() => {126    if (!mesh.current) return;127 128    const tl = gsap.timeline({129      paused: true,130    });131 132    tl.fromTo(133      mesh.current.position,134      {135        z: -4,136        y: -0.8,137      },138      {139        z: 0,140        y: 0,141        duration: 1.1,142        ease: "power3.out",143      }144    ).fromTo(145      mesh.current.rotation,146      {147        y: -1.2,148      },149      {150        y: 0,151        duration: 0.9,152        ease: "power2.out",153      },154      "<0.2"155    );156 157    timeline.current = tl;158    tl.play(0);159 160    return () => {161      tl.kill();162      timeline.current = null;163    };164  }, []);165 166  return (167    <group>168      <mesh ref={mesh}>169        <SharedGeometry />170      </mesh>171 172      <HtmlControls173        onReplay={() =>174          timeline.current?.restart()175        }176        onReverse={() =>177          timeline.current?.reverse()178        }179      />180    </group>181  );182}183 184function HtmlControls({185  onReplay,186  onReverse,187}: {188  onReplay: () => void;189  onReverse: () => void;190}) {191  // In a production demo, place these controls192  // in DOM adjacent to Canvas rather than inside193  // the WebGL scene. Kept separate here to make194  // timeline ownership explicit.195  return null;196}197 198function SpringMode() {199  const [selected, setSelected] =200    useState(false);201 202  const springs = useSpring({203    scale: selected ? 1.25 : 1,204    position: selected205      ? ([0, 0.45, 0] as const)206      : ([0, 0, 0] as const),207    rotation: selected208      ? ([0, Math.PI * 0.35, 0] as const)209      : ([0, 0, 0] as const),210  });211 212  return (213    <animated.mesh214      scale={springs.scale}215      position={springs.position}216      rotation={springs.rotation}217      onClick={() =>218        setSelected((value) => !value)219      }220    >221      <SharedGeometry />222    </animated.mesh>223  );224}

For a published interactive demo, put GSAP replay and reverse buttons in the normal DOM beside the canvas and pass their handlers into the scene rather than hiding interface controls inside WebGL. The important architecture remains the same: changing mode unmounts the previous animation owner before the next one receives the object.

This comparison exposes what three disconnected “move from zero to one” snippets cannot. useFrame responds continuously to scene input. GSAP exposes an authored playhead. The spring responds to a changing destination. They are not three syntaxes for the same job.

Mixing systems: separate ownership before adding libraries

Production scenes often need more than one animation owner.

A hero can use GSAP for its entrance, useFrame for a continuously changing shader, and a spring for a hover state after the entrance completes.The problem begins when those systems write to the same property without a handoff.

Suppose GSAP controls:

1group.current.rotation.y

while a frame callback also writes:

1group.current.rotation.y = pointer.x * 0.3;

The last writer wins. More importantly, ownership is now difficult to reason about.

A useful scene hierarchy separates those transforms:

1<group ref={introGroup}>2  <group ref={interactionGroup}>3    <ProductModel />4  </group>5</group>

GSAP can own the parent group during the entrance. Pointer interaction can own the child group. Another valid boundary is lifecycle: GSAP owns the property until the intro finishes, then the interactive writer becomes active. The implementation can vary. The principle should not:

One animated property should have one clear owner at a time.

frameloop="demand" changes the integration contract

A continuously rendered scene is straightforward: scene values change and R3F keeps drawing frames. Demand rendering is different.

When a canvas uses:

1<Canvas frameloop="demand">

R3F can stop rendering when nothing observable requires another frame. That is useful for scenes that spend meaningful time completely still.It also means an external animation library can mutate a Three.js property without R3F automatically knowing that another frame needs to be drawn.

R3F exposes invalidate() to request rendering in that situation. The current scheduler documentation keeps invalidation as part of the API.

A GSAP tween can therefore request a frame while it is active:

1"use client";2 3import {4  useLayoutEffect,5  useRef,6} from "react";7import {8  Canvas,9  useThree,10} from "@react-three/fiber";11import { gsap } from "gsap";12import type { Mesh } from "three";13 14function DemandTween() {15  const mesh = useRef<Mesh>(null);16  const invalidate = useThree(17    (state) => state.invalidate18  );19 20  useLayoutEffect(() => {21    if (!mesh.current) return;22 23    const tween = gsap.to(24      mesh.current.position,25      {26        x: 2,27        duration: 1,28        ease: "power2.out",29        onUpdate: invalidate,30      }31    );32 33    return () => {34      tween.kill();35    };36  }, [invalidate]);37 38  return (39    <mesh ref={mesh}>40      <boxGeometry />41      <meshStandardMaterial />42    </mesh>43  );44}45 46export function DemandScene() {47  return (48    <Canvas frameloop="demand">49      <ambientLight intensity={1.5} />50      <DemandTween />51    </Canvas>52  );53}

The contract is clear:

GSAP changes the property. invalidate() requests another R3F frame. R3F renders the result.

Do not add invalidation to every animation mechanically. A continuously rendered canvas already has frames arriving. This becomes relevant when the render strategy intentionally allows the scene to go idle.

Reduced motion: do not start the animation before you know the preference

A naive reduced-motion hook often begins with:

1const [reduced, setReduced] = useState(false);

The media query is then read after mount.That creates an awkward edge case: an intro can begin at full motion before the user’s preference has been resolved.

Representing “not checked yet” explicitly avoids that assumption:

1"use client";2 3import {4  useEffect,5  useState,6} from "react";7 8export function usePrefersReducedMotion() {9  const [reduced, setReduced] =10    useState<boolean | null>(null);11 12  useEffect(() => {13    const query = window.matchMedia(14      "(prefers-reduced-motion: reduce)"15    );16 17    const update = () => {18      setReduced(query.matches);19    };20 21    update();22 23    query.addEventListener("change", update);24 25    return () => {26      query.removeEventListener(27        "change",28        update29      );30    };31  }, []);32 33  return reduced;34}

An animation can now wait until the preference is known:

1function MotionAwareIntro() {2  const reduced =3    usePrefersReducedMotion();4 5  if (reduced === null) {6    return <StaticProduct />;7  }8 9  if (reduced) {10    return <StaticProduct />;11  }12 13  return <AnimatedProductIntro />;14}

The first render does not assume full motion. The reduced-motion version also does not need to be “the same camera flight, only faster.”

For a dramatic spatial move, the better alternative may be a static final composition or a short opacity change. For a decorative perpetual shader, it may be a still frame. For a hover effect, a smaller displacement may be enough.

Vault’s current dependency guidance makes the same broader recommendation: reduced motion can mean disabling movement, reducing distance, removing parallax or showing the resulting state immediately rather than blindly preserving the original effect.

The canvas is an interaction surface. It is not an accessibility exemption.

Keep essential copy and controls in semantic HTML where appropriate. Make hover-dependent interactions usable on touch. Preserve visible focus and keyboard operation for actual controls.

Profile the scene, not the animation-library logo

Choosing the correct owner does not make WebGL cheap. A transform tween and a fullscreen fragment shader are both “animation.” Their costs can be radically different.

Before shipping a motion-heavy R3F scene, test the production build and ask concrete questions:

• Does the canvas continue rendering while nothing is visually changing?
• What happens on a real mid-range phone rather than only a desktop development machine?
• Does device pixel ratio materially increase GPU cost?
• Are post-processing, particles, shader complexity, texture size or draw calls the actual bottleneck?
• Are Three.js objects or temporary vectors being allocated unnecessarily inside the frame loop?
• Are timelines, observers, listeners and other external resources cleaned up when components unmount?
• Is heavy WebGL code imported only where it is needed?
• Does the reduced-motion version remain coherent?
• Does touch input have a deliberate behavior?
• Do interactive DOM controls still work with keyboard and visible focus?

Vault’s live dependency documentation makes similar production recommendations for WebGL effects: keep browser-only work in client components, lazy-load heavy scenes where appropriate, run production builds, test mobile behavior and avoid running expensive canvas work unnecessarily.

Do not turn those questions into folklore such as “useFrame is faster” or “springs are more performant.” The renderer still pays for the scene you give it. Motion has to earn its place in the experience and in the frame budget.

Choose the owner, then tune the motion

Most React Three Fiber animation decisions can start with three questions.

• Does the value need to be recalculated continuously from scene state? Start with useFrame.
• Does the motion have authored beats, overlap and playhead logic? Start with GSAP.
• Does application state define a destination that may change while the object is still moving? Start with @react-spring/three.

Then inspect the edges.

• If two systems touch the same property, define an ownership boundary.
• If the canvas renders on demand, make external mutation visible to R3F.
• If the interaction has substantial spatial motion, design a reduced-motion alternative before the animation starts.
• If the scene is expensive, profile its actual rendering workload instead of ranking animation libraries by intuition.

Declarative React does not mean declarative every frame. It means declaring the parts of the experience that deserve durable state, then letting the right machine handle the motion in between.

Explore WebGL & 3D Effects to preview patterns using effect-specific Three.js, React Three Fiber, GSAP and WebGL stacks