Cinco bifurcaciones claras a partir de una pregunta central — identifica el tipo de motion y aparece la biblioteca adecuada.
🗺️ La matriz completa de las 5 libs
Cada biblioteca tiene una zona de victoria clara. Usar la opción correcta significa obtener resultados rápido; usar la equivocada significa iterar contra la herramienta. La matriz de abajo es la guía definitiva.
| Biblioteca | Ideal para | Ejemplo típico | Cuándo NO usar |
|---|---|---|---|
| GSAP | Línea de tiempo estructurada, coreografía fija | Introducción a SaaS, video de lanzamiento, secuencia de textos | Movimiento reactivo / físico (usa Framer) |
| D3 | Datos que se convierten en una historia animada | Bar chart race, mapa de calor, línea de tiempo | Animaciones sin datos (GSAP es más simple) |
| Three.js | Escenas 3D renderizadas como fotogramas | Rotación de producto, recorrido 3D, explicador 3D | Animaciones 2D simples (exagerado) |
| Lottie | Microanimaciones ligeras y rápidas | Clip para redes sociales, incorporación, ícono de marca | Escenas complejas o con datos (usa GSAP / D3) |
| Framer Motion | Movimiento reactivo, físico, spring | UI interactiva, transiciones de página, arrastre | Línea de tiempo fija de video (usa GSAP) |
🎞️ GSAP — cuando la coreografía es el mensaje
GSAP es la opción para cualquier video donde la secuencia importa: texto que entra en escena, elementos que se revelan en orden, coreografía fijada en la timeline. Intros de SaaS, videos de lanzamiento, presentaciones de producto.
GSAP por encima de Framer para coreografía fija
Framer Motion es excelente para el movimiento reactivo (el usuario interactúa y la UI responde). Pero, en un video renderizado, la línea de tiempo es fija: GSAP se adapta directamente a ella. Framer agrega una capa de abstracción física que no tiene sentido sin interacción.
Framer para movimiento reactivo y físico
Cuando el video simula una UI interactiva (drag, spring, inercia), Framer ofrece la física real. Es el único caso en que Framer supera a GSAP dentro de Remotion.
📊 D3 y Three.js — especialistas de dominio
D3 y Three.js son especialistas: cada uno resuelve un problema muy específico mejor que cualquier otra biblioteca. Fuera de ese ámbito, son overengineering.
📊 D3: los datos se convierten en animación
Proporciona los datos, describe el gráfico y Claude lo renderiza. D3 es la única biblioteca en la que los datos y la animación conviven en el mismo modelo: no necesitas convertir, mapear ni sincronizar nada manualmente.
- ✓Bar chart race con datos reales
- ✓Línea de tiempo interactiva (en el video)
- ✓Mapa de calor con transición
🧊 Three.js — perspectiva real
Para cualquier cosa que requiera profundidad tridimensional, iluminación y cámara, Three.js es el único camino. Vanilla para lo simple; R3F cuando necesitas composición en componentes.
- ✓Rotación de producto 3D
- ✓Recorrido por un entorno
- ✓Animación explicativa 3D
💡 Regla para elegir entre D3 y Three.js
¿Hay datos? Usa D3. ¿Hay un eje z? Usa Three.js. Si te estás preguntando «¿servirá aquí?», probablemente sí, pero si tuviste que pensarlo, quizá GSAP sea más sencillo para el caso.
✨ Lottie — velocidad por encima de todo
Lottie es la opción cuando la velocidad importa más que la complejidad. Microcontenido, clips para redes sociales, onboarding: la ruta más rápida del prompt a un resultado listo para producción. La biblioteca que Claude acierta más a la primera.
Motion limpio y bucle perfecto. El tipo que funciona en Reels sin parecer hecho con software.
Ilustraciones que se mueven para guiar al usuario. Son livianas, cargan rápido y son el estándar del mercado móvil.
Íconos animados, pantallas de carga, confirmaciones. Pequeños detalles que dan vida a la identidad.
🔷 Cuándo Lottie pierde
Animaciones con datos estructurados (usa D3), coreografías largas (usa GSAP) o escenas 3D (usa Three.js). Fuera de estas excepciones, si dudas entre Lottie y GSAP para algo simple, elige Lottie: es más rápido.
🔮 Las 4 reglas universales
Independientemente de qué lib elijas, hay cuatro reglas que siempre aplican. Son los principios que hacen que Claude Code + Remotion funcionen bien con cualquier biblioteca.
Instala la skill antes que nada
Los 28 archivos de reglas de Remotion en el contexto de Claude son lo que garantiza que el código generado sea correcto para renderizar video. Sin la skill, Claude genera código de navegador, no de renderizado.
Empieza con la versión más simple
Cualquier escena funciona con menos elementos de los que crees. Un cubo antes de una escena completa; un gráfico antes de un dashboard. Lo simple se resuelve en un prompt; lo complejo necesita varios.
Itera en la misma sesión
El contexto de la escena permanece en Claude mientras dure la sesión. Los ajustes de color, velocidad, geometría o diseño son prompts de seguimiento, no prompts nuevos desde cero.
Renderizado con la configuración correcta
Los FPS, la resolución y el códec afectan la calidad final. Antes de renderizar, confirma la configuración de remotion.config.ts — la skill guía hacia los valores correctos.
🚀 Ruta 2 completada — qué sigue
Ahora ya tienes el mapa completo de las libs y las reglas universales. La Ruta 3 — Proyectos pon todo esto en práctica: proyectos completos end-to-end con cada biblioteca, desde el prompt hasta el MP4 final.
✗ Lo que no funciona sin el mapa
- ✗Elegir la librería por familiaridad y no por el tipo de movimiento.
- ✗Usar GSAP para todo: funciona, pero añade complejidad innecesaria.
- ✗Intentar usar datos con Three.js: D3 es la herramienta adecuada.
✓ Con el mapa en mente
- ✓El primer prompt ya usa la lib correcta — menos iteración.
- ✓Salida production-ready más rápida.
- ✓Claude genera código más confiable cuando la biblioteca es la adecuada para el problema.
🎯 En la Ruta 3 vas a
- →Crea desde cero un video de introducción para SaaS con GSAP.
- →Crea un bar chart race con D3 a partir de datos reales.
- →Renderizar una escena de producto 3D con Three.js.
- →Crea un social clip completo con Lottie.
📌 Resumen de la Ruta 2
Siguiente ruta:
Ruta 3 — Proyectos: proyectos end-to-end con cada biblioteca, del prompt al MP4.