I Replaced Rive, GSAP, and Lottie with One Visual Runtime. Here's What Happened to Our React App.

Six months ago, our React app's animation stack looked like a dependency graveyard:

• Rive for interactive vector graphics
• GSAP for timeline-based UI animations
• Lottie for JSON animations imported from design
• Framer Motion for React-specific transitions
• Plus a few hand-rolled CSS animations for good measure

Four tools. Four mental models. Four runtime dependencies. And a growing gap between what designers shipped and what developers could maintain.

We consolidated everything into a single visual runtime. Here's what actually happened.

The Problem Nobody Talks About

Animation tools are great in isolation. The cracks appear when you need a single component to do multiple things:

• A button that plays a Rive animation on hover, transitions with Framer Motion on click, and shows a Lottie loading state
• A card that animates into view with GSAP, has hover states in Rive, and a pressed state in CSS
• A form that validates with Framer Motion shake animations, loads with Lottie spinners, and succeeds with a Rive celebration

Each tool handles its piece. None of them talk to each other. You end up writing coordination code that's more complex than the animations themselves.

What We Switched To

We moved to ExodeUI — a visual runtime that combines state machines with vector rendering. Instead of four tools plus coordination code, we have:

• One editor where designers define visual states as nodes
• One file format that stores both appearance and behavior
• One export that generates production React components
• One runtime that renders everything natively

The pitch sounds almost too clean. We were skeptical too.

What We Actually Gained

1. Eliminated three runtime dependencies

Removing Rive's .riv player, Lottie's JSON player, and GSAP's timeline engine from our bundle saved roughly 180KB gzipped. Not life-changing for desktop, but noticeable on mobile.

2. Design files became production code

The biggest win wasn't technical — it was process. Our designer builds components in ExodeUI with states wired in. The output is a React component. No more "here's the animation file, here's the Figma frame, here's the Zeplin link" handoff.

3. State management simplified

Before: animation state lived in GSAP timelines, component state lived in React hooks, and visual state lived in Rive files. Three sources of truth.

After: one visual state machine defines every state of the component. The exported React component has exactly one source of truth for its visual behavior.

4. Cross-platform without rewrites

We ship React for web and Swift for iOS. Previously, this meant rebuilding animations twice. ExodeUI exports to both from the same visual file. The iOS team stopped being a bottleneck for animation work.

What We Lost

Honest trade-offs:

1. Existing animations didn't auto-migrate

Our Rive and GSAP animations had to be rebuilt as state nodes. Simple animations (a fade-in, a slide-up) were straightforward. Complex chained timelines required rethinking the interaction as states rather than sequences.

2. The library effect

GSAP's plugin ecosystem (ScrollTrigger, MotionPath, MorphSVG) handles specialized cases we occasionally needed. ExodeUI's node system covers the common cases but doesn't have equivalents for scroll-driven complex path animations.

3. Team learning curve

Developers familiar with code-based animation had to shift to visual thinking. The first week was slow. By week two, the team was faster than before — because visual state machines are easier to reason about than chains of .to() calls.

Who This Is For

This worked for us because our product is an application — interactive forms, data displays, multi-state components, user onboarding flows. If you're building:

• A marketing site with scroll animations → stick with GSAP + CSS
• A social app with complex gesture interactions → ExodeUI's node system handles this well
• A design tool or game → evaluate based on your specific rendering needs
• A standard SaaS product → this is where the savings compound

The Numbers

Before: 4 animation tools, ~280KB of runtime dependencies, 3-person-week per cross-platform feature, constant handoff friction.

After: 1 visual runtime, ~90KB total, 1-person-week per cross-platform feature, designers ship directly.

Should You Do This?

If your team spends more time coordinating animation tools than building features, the consolidation is worth exploring. The first month requires patience (rebuilding, learning, debugging). After that, the velocity increase is real.

We open-sourced our migration guide templates — they're rough but functional. Happy to share if this resonates with your stack.

---

Built with ExodeUI. This post is honest — the migration was work, but the outcome justified it.