When to Build Your Own Animation Engine Instead of Using Lottie

The real cost of web animations isn't just file size—it's the black box effect that forces you to surrender control over your DOM.

A developer recently shared their decision to build a custom 20KB motion engine instead of using industry-standard tools like Lottie, Rive, or SVGator. While this might sound like NIH (Not Invented Here) syndrome, their reasoning exposes a genuine tension in modern web development: when do popular solutions become counterproductive?

The Hidden Weight of "Lightweight" Solutions

Lottie seems like the obvious choice for web animations. Export from After Effects, drop in a JSON file, call it done. But here's what actually happens:

1// What you think you're importing
2import animationData from './button-hover.json';
3
4// What you're actually bundling
5import lottieWeb from 'lottie-web'; // ~50KB+ runtime
6// Plus your animation JSON files
7// Plus DOM overhead for each instance

The author discovered that for UI-centric animations—think button hovers, loading states, micro-interactions—they were paying a massive overhead tax. Each animation required the full Lottie runtime, even for simple scale or opacity changes that could be handled with a few lines of CSS or JavaScript.

This "black box" problem becomes exponentially worse when you have dozens of animated components. Imagine an e-commerce site with animated product cards, loading states, and interactive buttons. Each component imports Lottie, creating bundle bloat and DOM complexity that scales poorly.

The DOM Integration Problem

Here's where things get interesting. Lottie and Rive render into isolated containers—usually a div with an SVG or canvas inside. This breaks fundamental assumptions about how web layouts work:

1/* You want this to work */
2.product-card {
3  display: flex;
4  align-items: center;
5}
6
7.product-card .animated-icon {
8  flex: 0 0 24px;

The animation lives in its own world, making it harder to style responsively or integrate with your component's lifecycle. Want to sync the animation with user scroll position? Good luck accessing Lottie's internal state machine.

When Custom Beats Popular

The author's 20KB engine wasn't built to replace After Effects workflows—it was optimized for a specific use case: UI animations that need tight DOM integration. Here's when building your own makes sense:

You have many small animations: If you're animating 50+ buttons, icons, or UI elements, the fixed cost of Lottie's runtime becomes prohibitive. A custom solution can be more efficient at scale.

You need DOM control: When animations need to work seamlessly with CSS Grid, Flexbox, or complex responsive layouts, black box solutions create friction.

State synchronization matters: If your animations need to sync with React state, user interactions, or API calls, having direct control over the animation engine is invaluable.

Performance is critical: On low-end devices or when many animations run simultaneously, every KB and DOM node counts.

The Engineering vs. Design Tension

This case study highlights a common disconnect between design and engineering workflows:

• Designers love visual tools like After Effects and SVGator because they can create complex animations without writing code
• Engineers care about bundle size, performance, maintainability, and framework integration

Neither perspective is wrong, but they optimize for different things. The key insight is recognizing when you're on the wrong side of the trade-off curve.

1// Designer-friendly (high fidelity, heavy)
2lottie.loadAnimation({
3  container: element,
4  renderer: 'svg',
5  loop: true,
6  autoplay: true,
7  animationData: complexHeroAnimation
8});

Making the Right Choice

Before building your own animation solution, consider this framework:

Use Lottie/Rive when:

• You have complex, After Effects-driven animations
• Design fidelity trumps bundle size
• You have fewer than 10-15 animated components
• You can lazy-load the runtime

Consider a custom solution when:

• You have many simple UI animations
• Bundle size is critical
• You need tight DOM integration
• You're already comfortable with animation APIs

Use CSS animations when:

• Animations are purely decorative
• You don't need programmatic control
• Performance is the top priority

Why This Matters

This story isn't really about animation engines—it's about recognizing when popular solutions become impediments. Every dependency is a trade-off between convenience and control. Sometimes the "industry standard" tool is overkill for your specific problem.

The next time you reach for a heavy library to solve a lightweight problem, ask yourself: am I optimizing for the right constraints? Sometimes the best solution is the one you build yourself, tailored exactly to your needs.

Start by auditing your current animation strategy. How much JavaScript are you shipping for animations? How many DOM nodes do they create? The answers might surprise you—and inspire you to think differently about the tools you choose.