DEV Community: Sugam Panthi

Part 2: Replacing a 3.4MB video with 40kb of scripted GSAP animations: adding a camera

Sugam Panthi — Wed, 27 May 2026 17:24:51 +0000

Part one reached 6,000 views on r/webdev in two days. I did not expect that. I wrote it because I thought replacing a 3.4 MB video with 40 KB of DOM animation was interesting enough to share. Turns out a lot of people are thinking about the same problem.

The comments were better than the post. People asked about SEO indexing, screen reader behavior, prefers-reduced-motion fallbacks, whether GSAP is even necessary, and several pointed out it was missing something. They were right.

Part one had a cursor clicking through scenes on a flat stage. Everything happened at the same zoom level, the same distance from the viewer. Watch a real product demo video and you notice something different: the camera moves. It zooms into the action when something important happens, follows the cursor through a workflow, and pulls back when the scene changes. That is the difference between a slide deck and a directed film.

This post adds the camera. Same 40 KB budget. No video files.

See the full post with 4 interactive demos, side-by-side comparisons, and a live FPS stress test

The zoom wrapper problem

The first thing you try is gsap.to(frame, { scale: 1.4 }). It works for half a second, then you notice your responsive scaling is gone. The film frame uses transform: scale(filmScale) to fit its container width, and GSAP just overwrote it. Both write to the same CSS transform property. They cannot coexist on the same element.

The fix is a wrapper inside the frame that GSAP owns:

<div data-film-frame style={{ transform: `scale(${filmScale})` }}>
  <div data-film-zoom className="origin-center">
    {/* All scene content */}
  </div>
  <Cursor />  {/* Outside the zoom wrapper */}
</div>

GSAP animates data-film-zoom. The responsive scale on the outer frame is untouched. The cursor lives outside the zoom wrapper, so it stays the same size while content scales up around it. This took me an embarrassing amount of time to figure out. Two divs. That was the whole fix.

Pan math

Zooming into the center of the frame is easy. Zooming into a specific element, like a Pinterest pin the user is about to right-click, is the real problem. You need to translate the zoom wrapper so the target ends up centered in the visible viewport:

const ZOOM = 1.45;
const panTo = (target) => ({
  x: (FILM_WIDTH / 2 - target.x) * (ZOOM - 1),
  y: (FILM_HEIGHT / 2 - target.y) * (ZOOM - 1),
});

At zoom 1.0, no translation needed. At zoom 1.45, every pixel away from center needs 0.45 times that distance in translation to compensate.

Stay zoomed, pan to follow

The biggest mistake in my first attempt was zooming in for one interaction, zooming out, zooming in for the next, zooming out again. It looked like a PowerPoint with a budget zoom transition.

The correct pattern: zoom in once, stay zoomed, pan to follow the cursor through the whole interaction sequence, zoom out once when changing scenes.

// Zoom in on right-click
tl.to(zoom, {
  scale: ZOOM, x: panPin.x, y: panPin.y,
  duration: 0.65, ease: "expo.out",
}, "zoomIn");

// Context menu while zoomed
tl.to(ctx, { autoAlpha: 1, duration: 0.16 }, "zoomIn+=0.35");

// Camera pans to follow cursor to the save button (still zoomed)
tl.to(zoom, {
  x: panSave.x, y: panSave.y,
  duration: 0.55, ease: "sine.inOut",
}, "panToSave");

// Only zoom out when done
tl.to(zoom, {
  scale: 1, x: 0, y: 0,
  duration: 0.45, ease: "sine.inOut",
}, "zoomOut");

See this running as a live interactive demo in the full post

Easing is not one-size-fits-all

Part one used power2.out for almost everything. Fine for a flat demo. But when you add camera movement, different motion types need different eases or the whole thing feels off.

Motion	Ease	Why
Camera pan	`sine.inOut`	Smoothest curve. Feels like a real camera on a dolly.
Dramatic zoom-in	`expo.out`	Fast start, long deceleration. Whoosh then settle.
Cursor movement	`sine.inOut`	Natural hand acceleration.
Fade in	`sine.out`	Decelerates into visibility.
Click squeeze	`power2.out`	Snappy press response.
Click release	`back.out(2.2)`	Slight overshoot. Feels physical.
Typed text	`none`	Real typing does not ease.

The single biggest upgrade was replacing power2.inOut with sine.inOut on camera moves. power2 has a noticeable acceleration kick that feels mechanical at large scale. sine has no perceptible kick at any point in the curve.

The cursor is never dead

With camera movement, there are moments where the scene shifts but the cursor is frozen. Those moments break the illusion. Every camera move should have a simultaneous cursor movement at the same timeline label:

// BAD: cursor is dead during zoom
tl.to(zoom, { scale: 1.4, x: panX, y: panY, duration: 0.7 }, "zoomIn");

// GOOD: cursor drifts toward its next target during zoom
tl.to(zoom, {
  scale: 1.4, x: panX, y: panY,
  duration: 0.7, ease: "expo.out",
}, "zoomIn");
tl.to(cursor, {
  x: current.x + (next.x - current.x) * 0.3,
  y: current.y + (next.y - current.y) * 0.3,
  duration: 0.65, ease: "sine.out",
}, "zoomIn");

The cursor does not need to arrive. A 20-30% drift toward the next target is enough. Calm, but never dead.

The full post has a side-by-side comparison of frozen vs drifting cursor during zoom

Graceful loops

Part one's loop was abrupt. With camera movement the problem is worse because the zoom jumps from 1.4x to 1.0 instantaneously.

The fix is an outro:

tl.to(zoom, { scale: 1, x: 0, y: 0, duration: 0.8, ease: "sine.inOut" }, "outro");
tl.to(cursor, { x: offScreenX, y: offScreenY, duration: 0.7, ease: "sine.in" }, "outro+=0.1");
tl.to({}, { duration: 0.6 }); // breathing room

And a timing rule: first drafts are always too slow. Cut 20-30% from your timing after the first working version.

SEO, theming, and the stuff video cannot do

View source on a <video> tag and Google sees <video src="demo.mp4">. A black box. View source on a GSAP demo and every button label, menu item, and heading is indexable text. I have not run a controlled ranking test, but logically: real DOM text beats an opaque binary blob.

Beyond indexing, DOM demos change when the product does. Marketing changes a button label? Change a text string. Brand color update? One hex value. You want the demo buttons to actually convert? Wire them to a real signup modal. A video cannot do any of that.

Accessibility

When prefers-reduced-motion: reduce is enabled, skip the entire timeline and render the resting state. GSAP's autoAlpha sets both opacity: 0 and visibility: hidden, removing elements from tab order and screen readers. Every hidden element uses autoAlpha, not opacity, so screen readers only see what is currently visible.

Does it need GSAP?

For simple animations, no. But the web clipper demo has roughly 50 coordinated animations across two scenes with camera movement. GSAP gives you labels (named beats), repeat: -1 with reset logic, gsap.utils.selector(root) for data-attribute queries, a full easing library, and stagger. You could build all of this without GSAP. It would take longer and produce worse results.

GSAP core is 28 KB gzipped. If you are orchestrating a 50-animation cinematic demo, it is infrastructure.

The agent reality

Five demos across the site, roughly 4,000 lines of choreography code. I wrote maybe 60% of that. An AI agent wrote the other 40%.

My 60% was the directing: deciding what to zoom into, choosing eases after watching both options, noticing the cursor felt dead during zooms, saying "the zoom-out is 200ms too slow." The agent cannot watch the animation and feel that something is off.

The agent's 40% was the implementation: 1,500 lines of timeline code, DOM elements, click helpers, reset blocks. Pattern-based work following rules I defined in a skill file. The patterns are stable enough that the output is consistent across different demos. But the agent does not know when something looks wrong. That part is still mine.

Performance

The web clipper demo has 50 .to() calls but only 3-5 are actively tweening at any frame. Every .to() writes to transform or opacity, both compositor-friendly. The full post has a live stress test with an FPS counter where you can push from 8 to 48 concurrent elements and watch the frame rate.

The updated math

Approach	Compressed	Camera?	Indexable?	Accessible?	Themeable?
GSAP (flat, part one)	~37 KB	No	Yes	Yes	Yes
GSAP (pan-zoom, part two)	~40 KB	Yes	Yes	Yes	Yes
15s MP4 (H.264)	2-4 MB	Baked in	No	No	No
15s WebM (VP9)	1-2 MB	Baked in	No	No	No
15s GIF	8-15 MB	Baked in	No	No	No

Adding the camera added roughly 3 KB to the bundle. All five production demos across costumary.com ship under 80 KB gzipped combined. The equivalent in video would be 15-20 MB.

Part one was proof you could replace a video. Part two is the part where it starts to feel directed instead of recorded.

The upfront cost is real. The ongoing cost is near zero. Updates are code changes, not re-recordings.

Full post with interactive demos: spanthi.com/blog/gsap-choreography-part-2

Production examples: costumary.com | costumary.com/web-clipper

Open source agent skill: gsap-choreography

Part 2: Replacing a 3.4MB video with 40kb of scripted GSAP animations: adding a camera

Sugam Panthi — Wed, 27 May 2026 17:24:50 +0000

Part one reached 69,000 views on r/webdev in two days. I did not expect that. I wrote it because I thought replacing a 3.4 MB video with 40 KB of DOM animation was interesting enough to share. Turns out a lot of people are thinking about the same problem.

This post adds the camera. Same 40 KB budget. No video files.

See the full post with 4 interactive demos, side-by-side comparisons, and a live FPS stress test

The zoom wrapper problem

The fix is a wrapper inside the frame that GSAP owns:

<div data-film-frame style={{ transform: `scale(${filmScale})` }}>
  <div data-film-zoom className="origin-center">
    {/* All scene content */}
  </div>
  <Cursor />  {/* Outside the zoom wrapper */}
</div>

Pan math

const ZOOM = 1.45;
const panTo = (target) => ({
  x: (FILM_WIDTH / 2 - target.x) * (ZOOM - 1),
  y: (FILM_HEIGHT / 2 - target.y) * (ZOOM - 1),
});

At zoom 1.0, no translation needed. At zoom 1.45, every pixel away from center needs 0.45 times that distance in translation to compensate.

Stay zoomed, pan to follow

The biggest mistake in my first attempt was zooming in for one interaction, zooming out, zooming in for the next, zooming out again. It looked like a PowerPoint with a budget zoom transition.

The correct pattern: zoom in once, stay zoomed, pan to follow the cursor through the whole interaction sequence, zoom out once when changing scenes.

// Zoom in on right-click
tl.to(zoom, {
  scale: ZOOM, x: panPin.x, y: panPin.y,
  duration: 0.65, ease: "expo.out",
}, "zoomIn");

// Context menu while zoomed
tl.to(ctx, { autoAlpha: 1, duration: 0.16 }, "zoomIn+=0.35");

// Camera pans to follow cursor to the save button (still zoomed)
tl.to(zoom, {
  x: panSave.x, y: panSave.y,
  duration: 0.55, ease: "sine.inOut",
}, "panToSave");

// Only zoom out when done
tl.to(zoom, {
  scale: 1, x: 0, y: 0,
  duration: 0.45, ease: "sine.inOut",
}, "zoomOut");

See this running as a live interactive demo in the full post

Easing is not one-size-fits-all

Part one used power2.out for almost everything. Fine for a flat demo. But when you add camera movement, different motion types need different eases or the whole thing feels off.

Motion	Ease	Why
Camera pan	`sine.inOut`	Smoothest curve. Feels like a real camera on a dolly.
Dramatic zoom-in	`expo.out`	Fast start, long deceleration. Whoosh then settle.
Cursor movement	`sine.inOut`	Natural hand acceleration.
Fade in	`sine.out`	Decelerates into visibility.
Click squeeze	`power2.out`	Snappy press response.
Click release	`back.out(2.2)`	Slight overshoot. Feels physical.
Typed text	`none`	Real typing does not ease.

The cursor is never dead

// BAD: cursor is dead during zoom
tl.to(zoom, { scale: 1.4, x: panX, y: panY, duration: 0.7 }, "zoomIn");

// GOOD: cursor drifts toward its next target during zoom
tl.to(zoom, {
  scale: 1.4, x: panX, y: panY,
  duration: 0.7, ease: "expo.out",
}, "zoomIn");
tl.to(cursor, {
  x: current.x + (next.x - current.x) * 0.3,
  y: current.y + (next.y - current.y) * 0.3,
  duration: 0.65, ease: "sine.out",
}, "zoomIn");

The cursor does not need to arrive. A 20-30% drift toward the next target is enough. Calm, but never dead.

The full post has a side-by-side comparison of frozen vs drifting cursor during zoom

Graceful loops

Part one's loop was abrupt. With camera movement the problem is worse because the zoom jumps from 1.4x to 1.0 instantaneously.

The fix is an outro:

tl.to(zoom, { scale: 1, x: 0, y: 0, duration: 0.8, ease: "sine.inOut" }, "outro");
tl.to(cursor, { x: offScreenX, y: offScreenY, duration: 0.7, ease: "sine.in" }, "outro+=0.1");
tl.to({}, { duration: 0.6 }); // breathing room

And a timing rule: first drafts are always too slow. Cut 20-30% from your timing after the first working version.

SEO, theming, and the stuff video cannot do

Accessibility

Does it need GSAP?

GSAP core is 28 KB gzipped. If you are orchestrating a 50-animation cinematic demo, it is infrastructure.

The agent reality

Five demos across the site, roughly 4,000 lines of choreography code. I wrote maybe 60% of that. An AI agent wrote the other 40%.

Performance

The updated math

Approach	Compressed	Camera?	Indexable?	Accessible?	Themeable?
GSAP (flat, part one)	~37 KB	No	Yes	Yes	Yes
GSAP (pan-zoom, part two)	~40 KB	Yes	Yes	Yes	Yes
15s MP4 (H.264)	2-4 MB	Baked in	No	No	No
15s WebM (VP9)	1-2 MB	Baked in	No	No	No
15s GIF	8-15 MB	Baked in	No	No	No

Adding the camera added roughly 3 KB to the bundle. All five production demos across costumary.com ship under 80 KB gzipped combined. The equivalent in video would be 15-20 MB.

Part one was proof you could replace a video. Part two is the part where it starts to feel directed instead of recorded.

The upfront cost is real. The ongoing cost is near zero. Updates are code changes, not re-recordings.

Full post with interactive demos: spanthi.com/blog/gsap-choreography-part-2

Production examples: costumary.com | costumary.com/web-clipper

Open source agent skill: gsap-choreography

Professional Scripted product demos with GSAP with Claude

Sugam Panthi — Thu, 21 May 2026 00:37:12 +0000

I was exporting a 15-second screen recording of the product for the landing page when the file hit 3.4 MB. On a phone it would letterbox. If the user had prefers-reduced-motion enabled, it would just... play anyway. I could not theme it, could not pause it at a specific scene, could not scrub to the materials tab when a user scrolled there. A video is a frozen artifact. The product it was supposed to show off is alive.

So I deleted the MP4 and built the walkthrough as a scripted GSAP animation. Pure DOM. No video file. Under 40 KB gzipped. Every element in the animation is a real element on the page, styled with the same tokens as the rest of the site.

See the live interactive demos running in your browser (two demos: a simple task app walkthrough and a Figma-style multi-cursor collaborative editor)

One cursor. One gsap.timeline(). Seven scenes. The cursor enters, clicks a button, cards stagger in with slight rotation offsets, an overlay appears, the scene cross-fades to a new tab, list items reveal, text types out character by character. When it finishes, it loops. Not a recording, not a GIF, not a video.

The problem with one timeline

My first instinct was multiple timelines: one for the cursor, one for the cards, one for the scene transitions. They drifted apart within seconds. If the user switched tabs and came back, the cursor was clicking on empty space where the cards used to be. Pausing one timeline did not pause the others.

The fix was to put everything on a single gsap.timeline() and use labels as the skeleton:

const tl = gsap.timeline({
  repeat: -1,
  repeatDelay: 1.2,
  defaults: { ease: "power3.out" },
});

Labels are named after what the user does, not what animates. "addClick" is the moment the cursor clicks Add. "navClick" is the moment it clicks Notes. Everything else positions relative to these with offsets like "addClick+=0.16".

The important consequence: inserting a new scene between two labels does not require recalculating any downstream timing. Labels absorb the shift.

What makes a cursor feel human

The cursor does not slide across the screen at constant speed. Real hands decelerate into a target, so every movement uses power2.out. Duration scales with distance: short hops take 0.4-0.6s, cross-screen travel takes 0.7-1.0s, entering from off-screen takes a full second.

The click is the hardest part to get right. Two things happen simultaneously: the cursor squeezes to 88% scale on press, and a ripple circle bursts outward from the click point.

function click(position, label) {
  tl.set(ripple, { x: position.x, y: position.y, scale: 0.2, autoAlpha: 0.55 }, label)
    .to(cursor, { scale: 0.88, duration: 0.08, ease: "power2.out" }, label)
    .to(ripple, { scale: 3.4, autoAlpha: 0, duration: 0.54, ease: "power2.out" }, label)
    .to(cursor, { scale: 1, duration: 0.16, ease: "back.out(2.2)" }, `${label}+=0.09`);
}

The back.out(2.2) on the release is the detail that matters. The cursor slightly overshoots back to full size, like a finger lifting off glass. Replace it with power2.out and the click looks mechanical.

Scenes cross-fade, state does not

When the cursor clicks "Notes", three things happen: the card grid fades out, the list view fades in, and the sidebar highlighting switches. The first two are animated. The third is instant.

tl.to(cardArea, { autoAlpha: 0, duration: 0.24 }, "navClick+=0.08");
tl.to(listView, { autoAlpha: 1, duration: 0.28 }, "navClick+=0.14");

I use autoAlpha instead of opacity everywhere. At zero, GSAP sets visibility: hidden as well, which pulls invisible elements out of the tab order and screen readers. Plain opacity: 0 leaves ghost elements capturing clicks.

The nav highlighting uses classList, not GSAP. State changes should be instant. Animating a nav highlight makes the interface feel laggy, not smooth.

Timing is the whole game

The cards stagger in at 70ms intervals with per-card rotation offsets ([-2, 1.5, -1, 2.5] degrees). Without the rotation, four cards appearing on a grid look like a spreadsheet loading. With slight tilts, they feel dropped onto a desk.

tl.to(cards, {
  autoAlpha: 1, y: 0, scale: 1,
  rotation: (i) => rotations[i],
  stagger: 0.07,
  duration: 0.46,
}, "addClick+=0.16");

The most counterintuitive rule: after every major action, do nothing. After the cards appear, there is 1.4 seconds of dead time before the cursor moves again. Viewers need time to register what changed. Removing the pauses makes the animation faster but incomprehensible.

The typed text uses ease: "none", constant speed. This is one of the rare cases where linear motion is correct. Eased typing looks like someone accelerating through a sentence.

The loop trap

The first time the animation looped, every card was already visible. The overlay was still showing. The cursor was in the wrong position.

The fix is a reset block at timeline position 0 that explicitly restores every animated property:

tl.add(() => {
  gsap.set(cursor, { x: CURSOR_START.x, y: CURSOR_START.y, scale: 1 });
  gsap.set(cards, { autoAlpha: 0, y: 26, scale: 0.82, rotation: 0 });
  gsap.set(overlay, { autoAlpha: 0, scale: 0.96, y: 10 });
  gsap.set(typed, { textContent: "" });
}, 0);

Miss one property and you see it immediately on the second loop. I missed rotation the first time and the cards snapped to their tilted positions before animating. A subtle jump that took twenty minutes to find.

The architecture

The production version is 1,800 lines across five files:

film-script.ts          -> data: scenes, cursor paths, timings
film-primitives.tsx     -> DOM: frame, sidebar, cursor SVG
film-panels.tsx         -> DOM: each tab's content
film-demo.tsx           -> GSAP: the entire choreography
animation-provider.tsx  -> React context: play/pause/restart

GSAP code lives in exactly one file. Everything else is inert markup with data-film-* attributes. A designer can rearrange the reference board without touching the timeline. The timeline targets elements by data attribute using gsap.utils.selector(root), so React refs do not need to thread through component boundaries.

Responsive scaling is a CSS transform from a fixed design width. The container holds the aspect ratio, the film renders at full size and scales down. Same proportions, same cursor positions, same timing at every viewport width. No media queries.

When this makes sense and when it does not

I am not going to pretend this replaces video everywhere. It does not.

If your product demo involves real user data, logged-in dashboards, or workflows that change weekly, record a video. Scripting a timeline that mirrors a live product exactly is maintenance you do not want. Every time the UI changes, the animation breaks. A screen recording takes five minutes to redo.

If your team does not have someone comfortable reading a 400-line timeline file, video. This approach has a learning curve. The demos in this article took real engineering time, not drag-and-drop. Or an agent on your behalf.

Where it works: product walkthroughs of a stable UI that you want to feel alive. Onboarding sequences where you need the cursor to hit exact targets. Landing pages where the hero asset is the heaviest thing on the page.

The math:

Approach	Raw	Compressed	Notes
GSAP core (gsap.min.js)	73 KB	28 KB gzip	Shared across all animations
One demo component	20 KB	5.5 KB gzip	Single scene walkthrough
Both demos together	115 KB	37 KB gzip	Everything in this article
15s 1080p MP4 (H.264)	2-4 MB	Does not compress further	Already codec-compressed
15s 1080p GIF	8-15 MB	Does not compress further	Worst option by far
15s 1080p WebM (VP9)	1-2 MB	Does not compress further	Best video codec, still 30x larger

See the production version

costumary.com runs four scenes: a drag-and-drop reference import with progress bars, a multi-cursor collaboration sequence where three users work simultaneously, a sidebar that collapses from labeled nav to icon-only while the workspace expands, and an AI assistant that receives a typed question and streams a contextual response. Under 40 KB where a video would have been three megabytes.

For agents

If you build with Claude Code, Cursor, or similar, you can get the skill here: gsap-choreography.