Animaciones con Propósito: CSS vs Librerías

La primera pregunta que hago antes de implementar una animación no es "cómo", sino "por qué". Una transición que no comunica cambio de estado, no guía la atención del usuario ni proporciona feedback de interacción es decoración. La decoración tiene un costo: bytes de JavaScript, ciclos de CPU y complejidad de mantenimiento. Ese costo necesita justificación.

CSS moderno cubre la mayoría de las necesidades de animación en interfaces web. Las transiciones manejan cambios de estado (hover, focus, active). Las animaciones con @keyframes gestionan secuencias complejas. Las custom properties permiten parametrizar valores dinámicamente. Y el IntersectionObserver activa estas animaciones cuando los elementos entran en el viewport, eliminando la necesidad de scroll listeners costosos.

/* Animación de entrada: 0KB de JavaScript adicional */
[data-animate] {
  opacity: 0;
  transform: translateY(24px);
  transition: opacity 0.6s ease, transform 0.6s ease;
}
[data-animate].visible {
  opacity: 1;
  transform: translateY(0);
}

/* vs GSAP equivalente: ~28KB gzipped */
gsap.fromTo(el, { opacity: 0, y: 24 }, { opacity: 1, y: 0 });

Las librerías se justifican en escenarios específicos. Las animaciones de layout (cuando un elemento cambia de posición dentro de un grid) requieren cálculos que CSS no puede resolver nativamente. Las secuencias complejas con timeline, donde la animación B depende del estado de la animación A, se gestionan con mayor elegancia en GSAP. Y las animaciones basadas en física — springs, bounces con parámetros dinámicos — son el territorio natural de Framer Motion.

En la práctica, mi regla es directa: si la animación puede resolverse con transition o @keyframes, se queda en CSS. Si requiere coordinación temporal, física simulada o manipulación de layout, se evalúa la librería mínima necesaria. El resultado habitual es que el 90% de las animaciones de un sitio son CSS puro, y el 10% restante justifica su dependencia con funcionalidad que CSS no puede replicar.

El rendimiento de las animaciones también depende de qué propiedades se animan. Las propiedades transform y opacity se procesan en la GPU sin provocar reflow del layout. Animar width, height, margin o padding obliga al navegador a recalcular el layout de toda la página en cada frame. Esta distinción técnica tiene más impacto en el rendimiento percibido que la elección entre CSS y JavaScript. // ANIMATION_BUDGET: OPTIMIZED