Las Animaciones CSS Nativas con Scroll Ya Están Aquí — Es Hora de Despedir tu Librería de JavaScript | Blanche

El Hábito de las Librerías que No Podemos Romper

Sé honesto: la última vez que un diseñador te entregó una animación de revelado activada por scroll, ¿cuánto tardaste en escribir npm install gsap? Para la mayoría de los equipos de frontend, ese reflejo está tan profundamente arraigado que nadie lo cuestiona. GSAP es excelente. Framer Motion es excelente. Pero hemos estado usando herramientas de precisión para clavar chinchetas, mientras el navegador construía silenciosamente un martillo mejor.

A partir de 2025, las animaciones controladas por scroll son una parte completamente ratificada de la especificación CSS — y el soporte de los navegadores ha cruzado un umbral que hace que su uso en producción no solo sea viable, sino que ignorarlo sería, podría argumentarse, irresponsable. Este no es otro artículo de curiosidades sobre "CSS ahora puede hacer X". Es un desafío directo: audita lo que estás enviando, porque una parte significativa de tu JavaScript de animación puede eliminarse hoy mismo.

Qué Te Ofrecen Ahora las Animaciones CSS con Scroll

La especificación de Scroll-driven Animations introduce dos mecanismos centrales: scroll timelines y view timelines. Estos te permiten vincular cualquier animación CSS con @keyframes al progreso del scroll en lugar del tiempo — sin event listeners, sin bucles requestAnimationFrame, sin thrashing de layout.

@keyframes fade-in-up {
  from { opacity: 0; transform: translateY(40px); }
  to   { opacity: 1; transform: translateY(0); }
}

.card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 40%;
}

Eso es todo. El elemento .card ahora se animará al entrar en el viewport — sin IntersectionObserver, sin manejadores de scroll, sin librería. El navegador lo gestiona todo a nivel del compositor.

Los Dos Tipos de Timeline que Necesitas Conocer

scroll() — vincula el progreso de la animación a la distancia total de desplazamiento de un contenedor. Perfecto para barras de progreso y desplazamientos parallax.
view() — vincula el progreso de la animación a la posición de un elemento dentro del viewport. Perfecto para animaciones de entrada/salida y efectos de revelado.

También puedes nombrar timelines usando scroll-timeline-name y view-timeline-name para orquestar animaciones entre elementos — una capacidad que antes requería JavaScript para coordinarse.

Soporte de Navegadores en 2025: Qué Significan Realmente los Vacíos

Chrome y Edge tienen soporte completo desde la versión 115. Firefox lanzó soporte completo en la versión 110. Safari es la excepción — el soporte parcial llegó en Safari 18.2 (finales de 2024), pero animation-range y los timelines con nombre siguen siendo inconsistentes.

El soporte global se sitúa en torno al 84-87% de los usuarios según cómo se analicen los datos. En la mayoría de los contextos de agencias — especialmente SaaS B2B, herramientas para desarrolladores o portfolios creativos — tu distribución de navegadores probablemente se inclina suficientemente hacia Chrome y Firefox como para que este número sea aún más alto en la práctica.

El punto clave: la falta de soporte en Safari no significa que tus animaciones se rompan. Significa que no se reproducen. Con una mejora progresiva adecuada (explicada más adelante), eso es un fallback perfectamente aceptable.

Rendimiento: Nativo vs. los Grandes Jugadores de JavaScript

Aquí es donde la conversación se vuelve incómoda para los defensores de las librerías.

El ScrollTrigger de GSAP funciona escuchando eventos de scroll en el hilo principal y actualizando los estilos de los elementos mediante JavaScript. Incluso con la excepcional optimización de GSAP, sigues ejecutando lógica en el hilo principal, provocando recálculos de estilos y — si animas transform u opacity — saltando entre límites de hilos.

Las animaciones CSS nativas con scroll se ejecutan completamente en el hilo del compositor para las propiedades transform y opacity. El hilo principal nunca interviene. Esto no es una mejora marginal.

"Las animaciones en el hilo del compositor no pueden verse afectadas por la ejecución de JavaScript pesado en el hilo principal. Cuando tu aplicación está haciendo trabajo real — procesando datos, renderizando componentes — las animaciones nativas con scroll siguen reproduciéndose sin problemas. Las animaciones de scroll controladas por JS no."

En el análisis de rendimiento real con Chrome DevTools, una página con 12 revelados de tarjetas activados por scroll usando timelines view() muestra cero trabajo de animación de scroll en el hilo principal. La implementación equivalente con GSAP muestra impactos constantes de 2–4ms en el hilo principal por cada frame de scroll — no catastróficos, pero acumulativos, y escalan mal con la complejidad.

El whileInView de Framer Motion es incluso más costoso. Pasa por el ciclo de reconciliación de React y usa callbacks de IntersectionObserver para disparar cambios de estado. En dispositivos Android de gama baja, este patrón presenta tirones visibles que el CSS nativo simplemente no tiene.

Comparación de tamaño de bundle:

GSAP core + ScrollTrigger: ~45kb minificado + comprimido con gzip
Framer Motion (completo): ~170kb
Animaciones CSS nativas con scroll: 0kb

Eso no es retórico. Cero bytes. Sin import, sin inicialización, sin dependencia que auditar.

Cinco Patrones Prácticos que Puedes Implementar Esta Semana

1. Indicador de Progreso de Scroll

@keyframes grow-bar {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

.progress-bar {
  position: fixed;
  top: 0; left: 0;
  width: 100%; height: 4px;
  background: #6c63ff;
  transform-origin: left;
  animation: grow-bar linear;
  animation-timeline: scroll(root);
}

Esto antes requería ~20 líneas de JavaScript. Ahora son seis declaraciones CSS.

2. Revelados de Sección Escalonados

Usa animation-delay con timelines view() para crear efectos de entrada escalonados sin orquestación con JavaScript:

.feature-card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 10% entry 50%;
}
.feature-card:nth-child(2) { animation-delay: 0.1s; }
.feature-card:nth-child(3) { animation-delay: 0.2s; }

3. Desplazamiento Parallax de Fondo

.hero {
  animation: parallax-shift linear;
  animation-timeline: scroll(root);
}
@keyframes parallax-shift {
  from { background-position: 50% 0%; }
  to   { background-position: 50% 40%; }
}

4. Contador de Sección Sticky

Los view timelines con nombre permiten que un elemento padre controle las animaciones de sus hijos — ideal para barras laterales fijas que reaccionan al progreso de scroll de su sección:

.section {
  view-timeline-name: --section-progress;
  view-timeline-axis: block;
}

.sticky-label {
  animation: label-fade linear both;
  animation-timeline: --section-progress;
  animation-range: contain;
}

5. Animaciones de Salida

La mayoría de las librerías JS manejan animaciones de salida. view() también:

.card {
  animation: reveal-and-fade linear both;
  animation-timeline: view();
  animation-range: entry 0% exit 100%;
}
@keyframes reveal-and-fade {
  0%   { opacity: 0; transform: scale(0.9); }
  20%  { opacity: 1; transform: scale(1); }
  80%  { opacity: 1; }
  100% { opacity: 0; }
}

Casos Extremos donde las Librerías JS Siguen Ganando

La honestidad importa aquí. Hay escenarios genuinos donde el enfoque nativo se queda corto:

Animaciones basadas en física: Las simulaciones de resorte, curvas de momentum e interacciones basadas en velocidad no tienen equivalente en CSS. GSAP y librerías como react-spring dominan este espacio.
Secuenciación compleja con lógica condicional: Si tu animación de scroll necesita bifurcarse según el estado del usuario, los datos o las capacidades del dispositivo — ese es territorio de JavaScript.
Scroll-jacking y mecánicas de scroll personalizadas: Los motores de scroll virtual (Lenis, Locomotive) que toman el control del scroll nativo para crear experiencias suaves y controladas no pueden replicarse en CSS.
Requisitos de paridad con Safari: Si tu contrato exige consistencia perfecta en todos los navegadores incluyendo Safari ≤ 18.1, necesitarás un polyfill o una estrategia de fallback con JS. El polyfill oficial scroll-timeline de Google funciona, pero añade peso de nuevo.
Scrubbing de timeline intrincado: Si los diseñadores necesitan controlar las animaciones hacia adelante y hacia atrás con precisión (piensa en sitios de narrativa interactiva de alto nivel), la API de timeline de GSAP es genuinamente más expresiva.

Notablemente ausentes de esa lista: revelados básicos con scroll, parallax, indicadores de progreso y animaciones de entrada — que representan la gran mayoría del trabajo de animación con scroll en un proyecto de agencia típico.

Mejora Progresiva: Implementando Animaciones Nativas con Scroll de Forma Segura Hoy

El enfoque correcto no es "esperar al 100% de soporte en navegadores". El enfoque correcto es una consulta de características limpia:

/* Estado base: visible, sin animación */
.card {
  opacity: 1;
  transform: none;
}

/* Mejorado: solo animar cuando está soportado */
@supports (animation-timeline: view()) {
  .card {
    opacity: 0;
    animation: fade-in-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 40%;
  }
}

Los navegadores sin soporte ven el estado final inmediatamente — el contenido siempre es accesible. Los navegadores compatibles obtienen la experiencia mejorada. Sin peso de polyfill, sin librería de detección, sin JavaScript necesario.

Esta es la mejora progresiva tal como siempre estuvo pensada: una única base de código, capacidad por capas, cero compromiso en la accesibilidad base.

Escribir Menos Código es una Característica, No un Compromiso

Existe una trampa psicológica en el desarrollo frontend donde la complejidad señala competencia. Enviar un timeline personalizado de GSAP con curvas de easing personalizadas parece más profesional que seis líneas de CSS. No lo es.

El mejor código es el que no tienes que escribir, mantener, actualizar, auditar por vulnerabilidades de seguridad ni explicar al próximo desarrollador del proyecto. Las características nativas del navegador vienen con documentación gratuita, optimización de rendimiento gratuita y longevidad gratuita.

La especificación de animaciones con scroll es estable, el soporte de los navegadores es viable para producción ahora mismo, y las ventajas de rendimiento son reales. El único argumento que queda para seguir usando una librería JavaScript por defecto para animaciones de scroll es la inercia — y eso no es un argumento.

Audita tu próximo proyecto. Lista todas las animaciones activadas por scroll. Pregúntate cuáles necesitan genuinamente JavaScript. Esa lista será más corta de lo que crees — y llevarla a cero debería ser el objetivo.

El hábito de las librerías es difícil de romper. Rómpelo de todas formas.