Build a Premium Anime.js Interactive Site Using a Claude Workflow

Why Anime.js and why now

The JavaScript animation ecosystem has settled. GSAP is the professional standard but its commercial license costs $150/year for revenue-generating sites. CSS animations cap out fast once you need sequencing or scroll-driven timelines. Framer Motion is React-only. Anime.js is MIT-licensed, framework-agnostic, weighs 17kb gzipped, and has the cleanest timeline API in the category. It also happens to be one of the libraries Claude knows thoroughly — the training data includes the full docs, a large number of CodePen examples, and years of Stack Overflow answers. That combination matters: you get a model that can reason about anime.timeline(), stagger delays, and SVG morphing without hallucinating the API surface.

The Claude angle here is not "AI writes my code so I don't have to think." It's more specific: Claude is good at translating a visual description into a sequenced animation timeline, which is the part that takes experienced developers the longest. Figuring out that the hero text should fade in at 0ms, the subtitle at 200ms, and the CTA at 400ms, with an easing curve that feels premium — that's where an hour disappears. Claude compresses that hour into a prompt.

The project setup

You don't need a framework for this. A Vite vanilla project keeps the feedback loop tight and keeps the output portable. If your actual project is a Next.js app, everything here drops in — you'll just wrap the Anime.js calls in a useEffect with a ref.

Anime.js v4 was released in early 2025. If you're installing fresh today you're getting v4, which changed the import path. The old import anime from 'animejs/lib/anime.esm.js' is gone. In v4:

Pin to the exact version in your package.json before you start prompting Claude. Tell Claude the version number in every prompt. This single step eliminates 90% of hallucination problems with this library — v3 and v4 have different APIs and the training data contains both.

The two-phase Claude workflow

@oluwaphilemon1's core insight is the order of operations: get Claude to plan the motion system before writing any animation code, and keep the HTML/CSS deliberately minimal so the motion layer has something clean to work with. A cluttered baseline DOM makes animation targeting messy, and Claude can't clean up your existing markup while simultaneously building animation timelines.

Phase 1 is structure. You describe the site, Claude gives you semantic HTML with stable class names, and minimal CSS that covers layout and typography only — no transitions, no transforms, nothing that will conflict with Anime.js later. You review it, adjust it by hand or with a follow-up prompt, and only then move to Phase 2.

Phase 2 is motion. You give Claude the exact HTML structure from Phase 1 and ask for the animation layer. Because Claude wrote Phase 1, it knows every class name and DOM shape, and the generated animations will actually target the right elements.

Here's what Phase 1 looks like for a SaaS landing page:

The output is clean enough that you can paste it into index.html and style.css without editing. The class names it generates — .hero-headline, .hero-subhead, .hero-cta-primary, .feature-card — become the vocabulary for Phase 2.

Phase 2: generating the animation layer

Once you have stable HTML, this is the prompt that generates a full motion system:

The output from this prompt is the kind of code that used to take me three hours to sequence correctly. It comes back in two minutes. The key is the specificity — easing names, exact delay values, scroll thresholds. When you give Claude vague requests ("make it feel smooth"), the output is generic. When you specify easeOutExpo at 700ms, you get exactly that.

What the generated timeline looks like

This is representative of what Claude produces for the page load sequence, and it's worth reading to understand the pattern:

Note what Claude does correctly here without being told: it sets initial opacity: '0' programmatically before the timeline starts, so there's no flash of visible content. That's a detail that bites people the first time they use Anime.js. The model knows it.

The SVG animation layer

This is where the workflow earns back the most time. SVG path animations — drawing lines, morphing shapes, pulsing icons — are painful to write by hand. The math for stroke-dasharray and stroke-dashoffset is fiddly. Claude handles it cleanly.

For feature section icons, here's a prompt pattern that works:

The output includes the helper function that calculates getTotalLength() at runtime, which is exactly right — you can't hardcode those values because they depend on the rendered path geometry.

The minimal-base principle in practice

The most important structural decision in this workflow is restraint in Phase 1. Every CSS transition you put on an element in Phase 1 will fight Anime.js in Phase 2. Every transform: translateX() in your base CSS will confound the animation starting values. The discipline is: CSS handles color, typography, layout, and sizing. Anime.js handles all motion.

This also means keeping your HTML shallow. A feature card that has five nested wrapper divs for styling reasons is hard to animate — Anime.js targets elements and animates their transform, so the element you animate needs to be the element that moves visually. Before Phase 1, sketch which elements move and make sure they're direct parents of visible content, not intermediary layout containers.

Iterating with follow-up prompts

The first pass from Claude is rarely final. The timelines are correct but the feel might be off — too fast, too stiff, wrong easing for the brand. The follow-up prompt pattern is simple:

Referencing a real site as a feel benchmark works better than adjectives alone. "Like Linear" or "like Stripe's homepage" gives Claude a concrete visual vocabulary to draw from. It knows what those sites feel like in motion.

After two or three iteration rounds, the diff between what Claude generates and what you'd ship is small enough to hand-edit directly. At that point you own the animation file and understand every value in it.

What this doesn't replace

Claude cannot watch your browser. It doesn't know that your .hero-mockup image is 2400px wide and causes layout shift on mobile, or that the social proof scroll animation glitches in Safari because of a compositing bug. The motion system it generates is correct JavaScript, but visual QA is yours. Test on real devices, check the Chrome Performance panel for jank (you want 60fps with no main thread blocking during animations — Anime.js uses requestAnimationFrame so this is usually fine), and verify that prefers-reduced-motion is respected.

For the reduced motion case, one additional prompt finishes the job:

Claude will wrap the motion-heavy parts in if (!window.matchMedia('(prefers-reduced-motion: reduce)').matches) correctly.