Scroll-Driven Animations y View Transitions: CSS nativo que reemplaza a GSAP y Framer Motion

En 2023, si querías una animación que respondiera al scroll, necesitabas ScrollMagic, GSAP ScrollTrigger o Intersection Observer + requestAnimationFrame. Para transiciones entre páginas, necesitabas un framework SPA — y aún así dolía. En 2026, ambas cosas se resuelven con CSS.

La especificación de Scroll-Driven Animations y la View Transitions API han alcanzado soporte cross-browser completo. No es una promesa futura: son herramientas que puedes —y deberías— usar en producción hoy.

Pero ojo: no todo lo que brilla es oro. En este artículo comparto lo que aprendimos en Mintec probando ambas APIs en proyectos reales, con datos de rendimiento concretos y un framework de decisión para elegir cuándo usar CSS nativo vs cuándo seguir reaching por GSAP o Framer Motion.

Cómo funcionan las Scroll-Driven Animations (sin JavaScript)

El principio es engañosamente simple: en lugar de que una animación avance con el tiempo (animation-duration), avanza con el scroll. Dos funciones hacen todo el trabajo pesado:

animation-timeline: scroll() — Vincula la animación al progreso del scroll del contenedor más cercano con scroll. Si el usuario ha scrolleado el 40% del contenedor, la animación está al 40%.

animation-timeline: view() — Vincula la animación a la visibilidad del propio elemento dentro del viewport. Una imagen aparece cuando entra al 20% desde abajo y completa la animación cuando está al 80% visible.

El resto es CSS clásico: un @keyframes normal, con from y to. La diferencia está en que el 0% y el 100% ahora representan progreso de scroll en lugar de tiempo transcurrido.

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

.reveal {
  animation: fade-in 1s ease-out;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Tres líneas de CSS. Sin Intersection Observer, sin scroll listeners, sin librerías. El navegador hace todo en el compositor thread.

Lo que nadie te dice de animation-range

Aquí está el primer gotcha que encontramos en producción. El shorthand de CSS animations tiene una trampa silenciosa:

/* Esto RESETEA animation-timeline */
.reveal {
  animation: fade-in 1s ease-out;
}

Si usas el shorthand animation, sobreescribes animation-timeline a su valor por defecto (normal). La solución es usar longhands o asegurarte de declarar animation-timeline después del shorthand.

En nuestro último proyecto con Astro + Cloudflare, migramos las animaciones de entrada de un sitio corporativo de ScrollMagic (que añadía ~31KB al bundle crítico) a CSS scroll-driven animations. El resultado: cero JavaScript para scroll detection, mismas animaciones, y una reducción de 120ms en INP p75.

View Transitions API: el fin de las SPA forzadas

La View Transitions API resuelve un problema que los desarrolladores web han intentado solucionar con trucos durante dos décadas: hacer que la navegación entre páginas se sienta fluida.

Cross-document View Transitions — es decir, transiciones entre páginas HTML normales en un MPA (Multi-Page Application) — llegaron a Chrome 126+, Firefox 128+ y Safari 18+. En 2026, los tres grandes motores las soportan.

La activación es casi ridícula:

/* En tu CSS global */
@view-transition {
  navigation: auto;
}

Esto habilita transiciones automáticas entre páginas. El navegador toma un screenshot de la página actual, navega, y crossfadea al nuevo estado. Pero el poder real está en personalizar qué elementos hacen match entre páginas usando view-transition-name:

/* En página A */
.main-header { view-transition-name: header; }

/* En página B */  
.main-header { view-transition-name: header; }

Cuando ambos elementos existen en la página de origen y destino, el navegador morph automáticamente de uno a otro en lugar de hacer crossfade. Esto da exactamente la misma sensación que las transiciones de Framer Motion's LayoutGroup, pero zero JavaScript y zero bundle cost.

View Transitions en Astro (y otros frameworks MPA)

Aquí hay un detalle clave que descubrimos implementándolo en mintec.co. Astro es un MPA por defecto — cada navegación es una solicitud HTTP completa. Esto hace que Astro sea un candidato perfecto para cross-document View Transitions, pero hay un matiz importante:

Astro v5+ incluye soporte nativo para View Transitions. Actívalo en el layout global:

---
import { ViewTransitions } from "astro:transitions";
---
<!doctype html>
<html>
<head>
  <ViewTransitions />
</head>
<body>
  <slot />
</body>
</html>

Esto hace tres cosas: inyecta el CSS @view-transition { navigation: auto; }, configura el JavaScript mínimo para que el navegador capture los elementos nombrados, y maneja el fallback para navegadores que aún no soportan la API (simplemente navegan sin transición).

El gotcha real: las transiciones de elementos nombrados funcionan mejor cuando ambos lados de la navegación renderizan el mismo DOM tree. En Astro, si tienes un layout que cambia entre rutas (por ejemplo, sidebar que desaparece en /blog/[slug]), necesitas asegurar que los elementos con view-transition-name existen o no en ambos lados. Elementos huérfanos causan flashes.

Framework de decisión: CSS nativo vs librería JS

En Mintec empezamos 2026 con una regla simple que ha funcionado bien:

La regla general: empieza asumiendo que puedes hacerlo con CSS. El 70% de las animaciones decorativas que solíamos implementar con librerías se pueden hacer hoy con scroll-driven animations o View Transitions. Cuando te topes con un caso donde necesitas control programático (play/pause/reverse, sequencing, stagger por índice), ahí sí, agrega GSAP. No al revés.

Datos de producción: lo que medimos

Migrar de ScrollMagic + GSAP a CSS scroll-driven animations en un sitio corporativo de tamaño medio nos dio estos resultados:

El ahorro no es solo técnico. Es tiempo de desarrollo, menos bugs cross-browser, y una experiencia más consistente para el usuario.

El futuro inmediato

View Transitions sigue evolucionando. Lo que viene en 2026-2027:

• @view-transition con clases CSS para diferentes tipos de navegación (atrás vs adelante)
• view-transition-group para elementos que se reordenan en listas (tipo FLIP animation)
• Morphing SVG entre estados de página
• Integración más profunda con el Navigation API (la nueva especificación que reemplaza a History API)

Scroll-Driven Animations, por su parte, está en un punto donde la especificación está completa y estable. Los próximos pasos son adopción en frameworks y tooling — herramientas de build que automaticen la detección de animaciones que pueden migrarse de JS a CSS.

Conclusión

2026 es el año en que finalmente podemos dejar de lamentar el peso de las librerías de animación. CSS scroll-driven animations y View Transitions API cubren la mayoría de los casos de uso que antes requerían 30-50KB de JavaScript adicional. No es que GSAP o Framer Motion hayan muerto — siguen siendo las herramientas correctas para escenarios complejos — pero han pasado de ser el default a ser la excepción.

En Mintec, nuestro framework de decisión es simple: si se puede hacer con animation-timeline o @view-transition, se hace con CSS. Punto. Las librerías JS solo entran cuando el caso lo exige.

Tu estrategia de animación web en 2026 debería empezar por responder una pregunta: ¿realmente necesitas JavaScript para eso?