Motion vs GSAP: ¿Necesitas ambas?

La mayoría de los proyectos en React deberían comenzar con Motion para animaciones basadas en componentes y estado, y añadir GSAP únicamente cuando surja una necesidad concreta: una línea de tiempo de scroll con scrubbing, secuenciación compleja o trabajo con SVG/canvas.

Quien haya intentado integrar una sección de scroll con pin y scrubbing en una aplicación React conoce bien el momento en que surge esta pregunta: la animación funciona, un re-render la elimina, y empiezas a preguntarte si elegiste la librería equivocada. Usar ambas es algo habitual, completamente compatible y, a menudo, la decisión correcta para sitios con mucho contenido; sin embargo, implica un segundo runtime y un segundo modelo mental, por lo que no debería ser la opción por defecto. Este artículo compara ambas herramientas en función de los criterios que realmente determinan la elección.

Dos hechos invalidan la mayoría de las comparaciones más antiguas. Motion (antes conocida como Framer Motion) ahora está disponible para React, JavaScript y Vue, y se importa desde motion/react en lugar de framer-motion. Ya no es exclusiva de React. Y GSAP ya no es de pago: gracias a Webflow, todo el conjunto de herramientas de GSAP es ahora gratuito, incluidos todos los plugins adicionales como SplitText y MorphSVG que antes eran exclusivos para miembros de Club GSAP, incluso para uso comercial.

¿En qué se diferencian Motion y GSAP?

La diferencia en el modelo mental lo es todo a la hora de decidir. Motion es declarativo (describes el estado final y la librería interpola), mientras que GSAP es imperativo y basado en líneas de tiempo, donde diriges cada paso con un control preciso sobre el tiempo y el easing.

En Motion, defines los valores objetivo como props y la librería determina la transición:

import { motion } from "motion/react";

<motion.div
  initial={{ opacity: 0, y: 20 }}
  animate={{ opacity: 1, y: 0 }}
  transition={{ duration: 0.4 }}
/>

Cuando los valores en animate cambian, Motion realiza automáticamente la transición entre ellos; las propiedades físicas como x y scale usan física de resortes por defecto, mientras que las propiedades visuales como opacity usan easing de interpolación. GSAP invierte este enfoque: escribes llamadas imperativas y las encadenas en una línea de tiempo para un control escalonado y secuenciado. Esa diferencia (describir el resultado vs coreografiar cada momento) predice qué herramienta se adapta mejor a un problema determinado mejor que cualquier benchmark.

Comparación de Motion vs GSAP en los criterios que importan

A continuación se presenta una comparación directa en los ejes que un desarrollador frontend evalúa al adoptar una librería de animación: modelo mental, integración, trabajo con scroll/líneas de tiempo, rendimiento, bundle, compatibilidad con frameworks y licenciamiento.

En cuanto a integración, Motion está diseñado para aplicaciones basadas en componentes: anima entre dos layouts cualesquiera con una sola prop layout, y AnimatePresence mantiene los elementos activos para que puedan animarse al salir del DOM. GSAP justifica su uso a través de las líneas de tiempo y ScrollTrigger, que es el estándar para la animación controlada por scroll.

En cuanto al rendimiento, ambas apuntan a 60fps en el uso típico, y el marketing de ninguno de los dos proveedores resuelve el debate. El motor híbrido de Motion ejecuta animaciones de forma nativa en el navegador usando la Web Animations API y ScrollTimeline, recurriendo a JavaScript cuando necesita física de resortes o seguimiento de gestos. La página principal de Motion afirma que sus APIs son “hasta un 90% más pequeñas que su alternativa en GSAP”, pero se trata de una cifra del propio proveedor, no de una medición neutral. Trátala como marketing. Lo que importa es el comportamiento en dispositivos reales. La reproducción de sesiones en páginas de producción detecta el tipo de fallos que los benchmarks pasan por alto: fotogramas perdidos en animaciones vinculadas al scroll, o desplazamiento de layout causado por una transición de entrada en un teléfono de gama media.

En cuanto al bundle, ambas son modulares. Motion es tree-shakable con un footprint reducido, y el núcleo de GSAP es ligero con plugins que se añaden a la carta. En cuanto al licenciamiento, Motion tiene licencia MIT, y GSAP ahora se distribuye bajo una licencia estándar gratuita.

¿Cuándo deberías usar Motion vs GSAP?

Opta por Motion para interfaces de usuario basadas en estado: transiciones de entrada/salida con AnimatePresence, animaciones de layout automáticas, gestos y transiciones de página dentro de un árbol de componentes. Se integra de forma natural con el ciclo de renderizado de React, por lo que las animaciones responden al estado y las props sin necesidad de configuración manual.

Opta por GSAP para set-pieces secuenciados y con scrubbing: narrativas de scroll vinculadas con ScrollTrigger, líneas de tiempo escalonadas, y animación de SVG o canvas que Motion no contempla. GSAP anima CSS, SVG, canvas, React, Vue, WebGL, colores, cadenas de texto y trayectorias de movimiento: la amplitud de la que dependen los sitios de marketing y el trabajo de visualización de datos. Ambas librerías pueden respetar prefers-reduced-motion, por lo que la accesibilidad no es un factor decisivo; trátala como una responsabilidad compartida en cualquier caso.

¿Necesitas ambas?

Sí: es habitual y está completamente soportado usar ambas, Motion para micro-interacciones a nivel de componente y GSAP para set-pieces de scroll y líneas de tiempo. La combinación es un camino de primera clase en React. useGSAP() del paquete @gsap/react es un reemplazo directo de useEffect()/useLayoutEffect() que gestiona automáticamente la limpieza, y utiliza la técnica de layout-effect isomórfico, por lo que es seguro en entornos de renderizado en servidor, incluido el App Router de Next.js, siempre que el componente sea un componente cliente:

"use client";
import { useRef } from "react";
import gsap from "gsap";
import { useGSAP } from "@gsap/react";

gsap.registerPlugin(useGSAP);

function Hero() {
  const container = useRef(null);
  useGSAP(() => {
    gsap.from(".title", { y: 40, opacity: 0, duration: 0.6 });
  }, { scope: container });

  return (
    <section ref={container}>
      <h1 className="title">Hello</h1>
    </section>
  );
}

El coste de usar “ambas” es real: dos runtimes de animación implican un peso de bundle acumulado y dos modelos mentales para el equipo. Añade la segunda librería únicamente cuando aparezca una necesidad concreta, no por defecto. En la práctica, esto significa que Motion se encarga de tus botones, modales y transiciones de layout, mientras que GSAP gestiona esa sección de narrativa de scroll con la que Motion te daría problemas.

El veredicto

Recomendación por defecto para una aplicación React: comienza solo con Motion, e introduce GSAP la primera vez que necesites una línea de tiempo de scroll con scrubbing, secuenciación compleja o trabajo con SVG/canvas. Sin embargo, si un proyecto es principalmente narrativa basada en scroll, comienza con GSAP y recurre a Motion solo si la animación basada en estado de componentes crece. Ambas están actualizadas, son gratuitas y compatibles con múltiples frameworks, por lo que la decisión es de adecuación, no de licenciamiento. Elige la que mejor se ajuste a tu patrón de animación dominante, fija las versiones (Motion v12.42.2, GSAP v3.15.0) y añade la segunda solo cuando un requisito real lo exija.

Preguntas frecuentes

¿Framer Motion está muerta? ¿Qué le ocurrió?

Framer Motion no está muerta; fue renombrada como Motion y se convirtió en un proyecto independiente en 2024, expandiéndose más allá de React para dar soporte también a JavaScript y Vue. Ahora se instala el paquete 'motion' y se importa desde 'motion/react' en lugar de 'framer-motion'. Sigue teniendo licencia MIT y se mantiene activamente en la línea v12. Los tutoriales más antiguos que hacen referencia a las importaciones de 'framer-motion' siguen funcionando a través de una ruta de compatibilidad, pero los proyectos nuevos deberían usar el nombre de paquete actual.

¿GSAP sigue siendo de pago, o necesito una licencia de Club GreenSock?

GSAP es ahora completamente gratuito, incluidos todos los plugins que antes eran de pago, como SplitText, MorphSVG, DrawSVG, ScrollTrigger y ScrollSmoother. Tras la adquisición de GreenSock por parte de Webflow en 2024, el acceso de pago fue eliminado el 30 de abril de 2025, y la licencia estándar se amplió para cubrir el uso comercial. La librería es gratuita para todos, independientemente de si usas Webflow o no, por lo que no se requiere ninguna membresía de Club GreenSock para acceder a ninguna funcionalidad.

¿Puedo usar Motion y GSAP juntas en un proyecto con el App Router de Next.js?

Sí. Usa el hook oficial useGSAP() de GSAP del paquete '@gsap/react', que gestiona la limpieza y el modo estricto de React, y marca el componente con la directiva 'use client', ya que los componentes del App Router son componentes de servidor por defecto. useGSAP() utiliza la técnica de layout-effect isomórfico, por lo que es seguro para SSR siempre que se ejecute en un componente cliente. Los componentes de Motion funcionan en el mismo árbol para animaciones de estado y layout sin conflictos.

¿Motion soporta animaciones activadas por scroll, o sigo necesitando ScrollTrigger de GSAP?

Motion soporta animación vinculada al scroll a través de su hook useScroll y ScrollTimeline nativo, lo que cubre efectos comunes como barras de progreso y parallax vinculados a la posición de scroll. Para narrativas de scroll con scrubbing, secuenciadas con precisión, con pinning, snapping y líneas de tiempo complejas, ScrollTrigger de GSAP ofrece mayor control y es el estándar establecido. Si tu trabajo con scroll es una vinculación directa entre el progreso de scroll y un valor, Motion es suficiente; recurre a ScrollTrigger cuando la coreografía se vuelva compleja.