El censo de librerías: qué queda por resolver en 2026

Hace diez años una librería de animación resolvía un problema evidente: el navegador no sabía interpolar nada decente y jQuery.animate iba a tirones. Hoy el navegador tiene transitions, keyframes, WAAPI, timelines de scroll y View Transitions, y aun así el mercado de librerías está más vivo que nunca. La pregunta interesante no es cuál es mejor, sino qué problema concreto sigue sin resolver la plataforma y cuál de esos problemas tienes tú.

Lo que la plataforma sigue sin darte

Cuatro huecos, y conviene tenerlos separados porque cada librería ataca unos y no otros.

Secuenciación. CSS y WAAPI saben animar una cosa. No saben decir “esto empieza doscientos milisegundos antes de que termine aquello, y si cambio la duración del primero el segundo se mueve solo”. Puedes emular una timeline sumando delay a mano, y funciona hasta que alguien cambia una duración y tienes que recalcular quince números. No hay ninguna primitiva nativa de composición temporal: getAnimations() te da la lista de animaciones vivas, pero no un objeto que las gobierne como una unidad con su propio currentTime.

Interrupción con estado. La transición nativa interrumpida hace lo correcto en el caso fácil: sales de :hover a mitad de camino y el motor interpola desde el valor computado actual. En el caso difícil no. Si lo que quieres es que un elemento en movimiento cambie de destino conservando su velocidad —que es lo que hace un muelle— necesitas conocer la derivada en el instante de la interrupción, y CSS no expone eso. Los muelles no son un capricho estético: son el modelo que hace que una interrupción no se note.

Estado declarativo. En un framework, el estado de la interfaz vive en variables y el DOM es una función de ese estado. Las animaciones nativas viven en el lado opuesto: son efectos imperativos que aplicas sobre nodos concretos, con un ciclo de vida propio que tu framework desconoce. El caso que lo rompe todo es la salida: cuando el estado dice que el elemento ya no está, el framework lo desmonta, y no hay nada que animar. @starting-style y transition-behavior: allow-discrete resuelven una parte, pero solo si el elemento sobrevive en el DOM el tiempo suficiente, y eso es exactamente lo que el framework no te garantiza.

Lo que no es interpolable. Morfear un path de SVG a otro con distinto número de puntos, dividir un párrafo en líneas cuando el usuario cambia el ancho de la ventana, arrastrar con inercia y rebote contra los límites. Nada de esto es un problema de animación: es un problema de geometría y de entrada, y la parte de animación es la parte fácil.

Ninguna librería cubre los cuatro huecos igual de bien. Ahí está toda la conversación.

Los tres ejes que separan a unas de otras

Casi todas las comparativas que encontrarás ordenan las librerías por popularidad o por peso. Ninguna de las dos cosas predice si vas a estar cómodo con la elección dentro de dos años. Estos tres sí.

Paradigma: imperativo o declarativo. Una API imperativa te da verbos: anima esto de aquí a allá. Tú decides cuándo se llama. Una API declarativa te da un mapeo: cuando el estado sea abierto, este elemento se ve así, y cuando sea cerrado, así. La librería se encarga de detectar el cambio y de interpolar. La diferencia práctica es quién es responsable de la corrección cuando el estado cambia dos veces seguidas y rápido. En el modelo imperativo, tú. En el declarativo, la librería.

Motor: WAAPI o bucle propio. Una librería puede delegar la interpolación en el navegador llamando a element.animate(), o puede escribir valores en el estilo en línea desde su propio requestAnimationFrame. Delegar es más barato en bytes y permite que animaciones de transform y opacity corran en el hilo del compositor sin que la librería haga nada. Un bucle propio te permite animar lo que quieras —propiedades de un objeto JavaScript, atributos de SVG, valores que ni siquiera son CSS—, componer varias animaciones sobre el mismo elemento con reglas que tú controlas, y saber en todo momento la velocidad instantánea de cada valor. Las librerías serias de 2026 son híbridas: usan WAAPI cuando pueden y caen al bucle propio cuando no.

Acoplamiento: al framework o agnóstica. Una librería acoplada a React puede ver el árbol de componentes, saber que un nodo va a desmontarse y retrasarlo. Una agnóstica no puede saber eso y necesita que tú se lo digas. A cambio, la agnóstica sobrevive a que el equipo migre de framework, funciona igual en la landing estática que en la aplicación, y no te obliga a que cada nodo animado sea un componente.

Estos tres ejes son ortogonales y explican casi todas las discusiones. “Motion frente a GSAP” no es una comparación entre dos librerías: es una comparación entre declarativo-acoplado-híbrido e imperativo-agnóstico-bucle propio.

Quién es quién

Dos aclaraciones de nomenclatura que ahorran confusión.

Framer Motion se llama Motion desde 2024. El paquete es motion; el punto de entrada de React es motion/react. No es un fork ni un renombrado de marketing: el proyecto salió de Framer, se mantiene de forma independiente y añadió una API vanilla y adaptadores para Vue. Los tutoriales que dicen import { motion } from "framer-motion" siguen funcionando por compatibilidad, pero es código viejo.

Popmotion ya no existe como proyecto separado. Fue la librería de bajo nivel sobre la que se construyó Framer Motion, del mismo autor, y acabó absorbida dentro de Motion. Su dominio redirige. Si una comparativa de 2026 te lo presenta como una opción viva, está copiando de una comparativa de 2019.

Los criterios que no predicen nada

El tamaño del bundle, tomado en abstracto. Es el argumento favorito de las comparativas y el que peor envejece. Importa cuánto pesa lo que de verdad envías, no cuánto pesa el paquete completo, y casi todas estas librerías tienen entradas parciales. Y sobre todo: importa en relación con lo que ya envías. Veinte kilobytes en una landing de producto que ya carga cuatrocientos de framework no son una decisión de ingeniería, son una excusa. En una página de documentación estática con doce kilobytes totales, sí lo son. El número solo significa algo dividido por tu presupuesto.

Las estrellas de GitHub. Miden cuándo un proyecto fue popular, no si lo es. Una librería de 2016 con cincuenta mil estrellas y dos mantenedores desaparecidos es peor apuesta que una de 2023 con ocho mil y publicación mensual.

La demo de la portada. Todas son espectaculares. Todas están hechas por alguien que conoce la librería de memoria y ha dedicado dos días a esos ocho segundos. No te dicen nada sobre cómo se comporta la librería cuando cinco personas tocan el mismo componente durante un año.

Lo que sí predice: si el paradigma encaja con cómo escribís el resto de la interfaz. Un equipo que trabaja con componentes y estado va a pelearse con una API imperativa en cada cambio de estado, y un equipo que hace piezas de narrativa con scroll va a pelearse con una API declarativa en cada secuencia de doce pasos. La incomodidad se paga todos los días.