View Transitions API: cómo crear aplicaciones web con transiciones nativas sin depender de un framework
Durante años, una de las principales ventajas visuales de las aplicaciones de una sola página, conocidas como SPA, ha sido su capacidad para cambiar de pantalla sin recargar completamente el documento. Frameworks como React, Angular o Vue permiten mantener el estado de la aplicación y construir experiencias fluidas, pero también han contribuido a que asociemos las transiciones modernas con arquitecturas cada vez más complejas.
La plataforma web está cambiando esa situación. View Transitions API permite al navegador animar los cambios entre dos estados visuales, tanto dentro de un mismo documento como durante determinadas navegaciones entre páginas HTML diferentes. Esto significa que una aplicación multipágina puede ofrecer transiciones similares a las de una SPA sin tener que convertir toda su navegación en un sistema JavaScript.
En este artículo vamos a analizar cómo funciona esta API, por qué es relevante para el desarrollo web actual y cómo incorporarla a una aplicación real con ejemplos de JavaScript y CSS.
Por qué View Transitions vuelve a ser un tema de actualidad
La API no apareció en 2026. Chrome incorporó las transiciones dentro de un mismo documento en 2023 y amplió el soporte a navegaciones entre documentos en 2024. Sin embargo, durante 2025 y 2026 se han producido avances relevantes en compatibilidad y funcionalidades, incluido el soporte de transiciones dentro de un documento en Firefox 144 y la incorporación de waitUntil() en Chrome 144.
La importancia de esta evolución no está en una nueva animación, sino en que los navegadores están asumiendo una responsabilidad que antes solíamos resolver mediante bibliotecas, routers y bastante código de coordinación.
Esto encaja con una tendencia más amplia del desarrollo web: aprovechar capacidades nativas antes de introducir dependencias para resolver problemas que el navegador ya puede gestionar.
Qué es View Transitions API
View Transitions API es una interfaz de la plataforma web que permite crear una transición visual entre un estado anterior y uno nuevo. En lugar de obligarnos a calcular manualmente las posiciones de los elementos, el navegador captura los estados necesarios y genera una animación basada en CSS.
El proceso, simplificado, es el siguiente:
- El navegador captura el estado visual anterior.
- Se actualiza el DOM o se realiza la navegación.
- Se captura el estado visual nuevo.
- El navegador anima la transición entre ambos estados.
La API utiliza seudoelementos CSS específicos, como ::view-transition-old() y ::view-transition-new(), para representar las imágenes del estado anterior y del nuevo durante la animación.
Lo interesante es que existen dos formas principales de utilizarla: dentro de un mismo documento y entre documentos diferentes.
Transiciones en una SPA: actualizar el DOM sin un salto visual
Imaginemos una aplicación que muestra una lista de productos. Al seleccionar uno, queremos sustituir la lista por una vista de detalle sin que el cambio resulte brusco. Una implementación tradicional puede utilizar animaciones CSS, controlar cuándo se desmontan los componentes y coordinar el estado de entrada y salida.
Con View Transitions podemos delegar parte de esa coordinación en el navegador.
Un ejemplo básico con JavaScript
Supongamos que tenemos este HTML:
Y queremos sustituir el contenido al pulsar el botón:
El ejemplo es deliberadamente sencillo: no utiliza ningún framework ni gestiona un router. La llamada a document.startViewTransition() recibe una función encargada de actualizar el DOM. El navegador captura el estado anterior, ejecuta esa actualización y prepara la transición hacia el nuevo estado.
Si el navegador no soporta la API, el contenido se actualiza igualmente. Esta degradación progresiva es importante: la animación debe mejorar la experiencia, no convertirse en un requisito para utilizar la aplicación.
En una aplicación real, la función de actualización sería sustituida por el renderizado del framework, un cambio de estado o la navegación del router.
Personalizar la animación con CSS
Por defecto, el navegador aplica una transición de fundido entre los estados. Podemos modificarla utilizando los seudoelementos de View Transitions.
El nombre root hace referencia a la transición del documento completo. Esto resulta útil para cambios sencillos de pantalla, pero la API también permite identificar elementos concretos para que el navegador anime su transformación entre dos vistas.
Animar un elemento compartido: de tarjeta a detalle
Uno de los usos más interesantes es la transición de un elemento compartido. Por ejemplo, una imagen de producto que aparece en una tarjeta y después ocupa una posición mayor en la página de detalle.
Para conseguirlo, asignamos el mismo view-transition-name al elemento correspondiente en ambos estados:
En la vista de listado:
Y en la vista de detalle:
El navegador puede relacionar ambos elementos y animar el cambio de tamaño y posición. No necesitamos calcular las coordenadas de origen y destino ni mantener dos elementos superpuestos mediante JavaScript.
Hay una condición importante: los nombres deben ser únicos dentro del ámbito de cada transición. Si varias tarjetas visibles comparten el mismo nombre, podemos provocar que la transición no se ejecute correctamente. Para listas dinámicas conviene asignar el nombre únicamente al elemento seleccionado o utilizar estrategias de nombres únicos.
La diferencia decisiva: transiciones entre páginas HTML
Hasta aquí seguimos trabajando dentro de un mismo documento, algo habitual en una SPA. La parte que realmente cambia el planteamiento arquitectónico es la posibilidad de animar navegaciones entre documentos.
Imaginemos una web construida con Astro, una aplicación renderizada en servidor o incluso páginas HTML tradicionales. Cada enlace carga un documento nuevo desde el servidor. Antes, conseguir una transición coordinada entre ambas páginas requería interceptar la navegación y construir una capa JavaScript adicional.
Ahora podemos habilitar transiciones entre documentos del mismo origen con una regla CSS:
Esta regla debe estar presente en las dos páginas participantes. Cuando se produce una navegación compatible, el navegador puede realizar automáticamente la transición.
Por ejemplo:
No hay que sustituir el enlace por un botón ni interceptar el clic con JavaScript. El enlace continúa siendo una navegación HTML normal.
Ejemplo de estructura multipágina
Podríamos tener una aplicación con esta estructura:
Tanto la página de listado como la de detalle cargarían el mismo CSS:
La navegación sigue funcionando aunque el navegador no soporte la transición. Esta es una ventaja de utilizar enlaces reales y mantener la funcionalidad independiente del efecto visual.
Las limitaciones que conviene conocer
Las transiciones entre documentos tienen requisitos y limitaciones. En particular, deben producirse entre documentos del mismo origen y ambos deben habilitar la funcionalidad. No se aplican a cualquier navegación externa ni sustituyen el comportamiento habitual de todos los enlaces del navegador.
Tampoco debemos asumir que todas las funcionalidades avanzadas están disponibles en todos los navegadores. El soporte de las transiciones dentro de un documento y el de las transiciones entre documentos no es exactamente el mismo. Antes de utilizar características avanzadas en producción, es necesario consultar las tablas de compatibilidad y probar los navegadores que realmente utilizan nuestros usuarios.
¿Significa esto que las SPA dejan de tener sentido?
No. Sería una conclusión equivocada.
Una SPA no existe únicamente para animar cambios de pantalla. También permite mantener estado en memoria, gestionar interacciones complejas, evitar determinadas recargas, coordinar múltiples componentes y construir interfaces que se comportan como una aplicación de escritorio.
View Transitions resuelve un problema visual y de coordinación de estados, pero no sustituye una arquitectura de aplicación.
La diferencia es que ahora tenemos una razón menos para elegir una SPA cuando lo que realmente necesitamos es una web de contenido, un catálogo, una documentación o una aplicación con navegación relativamente sencilla.
Una MPA puede seguir ofreciendo ventajas como HTML generado en servidor, menor dependencia de JavaScript para la navegación y una arquitectura más simple. View Transitions permite mejorar su experiencia visual sin renunciar a esas características.
Cómo encaja con React, Angular y otros frameworks
La API es nativa, pero eso no significa que debamos dejar de utilizar frameworks. Su papel es complementario.
En React, por ejemplo, puede utilizarse para coordinar cambios visuales asociados al estado o al router. En Angular, una navegación o una actualización de componentes puede beneficiarse de las capacidades nativas cuando la integración del framework y del navegador lo permita. Frameworks orientados a contenido, como Astro, también pueden aprovechar las transiciones entre documentos o proporcionar integraciones específicas.
Lo importante es separar responsabilidades. El framework gestiona componentes, estado y lógica de aplicación; el navegador puede encargarse de parte de la transición visual. Así evitamos introducir una biblioteca de animación completa cuando únicamente necesitamos animar un cambio de vista.
No obstante, para animaciones complejas, secuencias cinematográficas, físicas, gestos avanzados o interacciones con control preciso de la línea temporal, herramientas especializadas como GSAP pueden seguir siendo más adecuadas.
Accesibilidad: no todos los usuarios quieren animaciones
Una transición visual no debe perjudicar a quienes prefieren reducir el movimiento. El navegador expone esta preferencia mediante la media query prefers-reduced-motion.
Podemos utilizarla para desactivar las animaciones de View Transitions:
En una aplicación real también conviene revisar los elementos animados individualmente, especialmente cuando hay desplazamientos grandes, zoom o efectos que pueden resultar molestos.
La accesibilidad no consiste únicamente en ofrecer una alternativa cuando la API no está soportada. También implica respetar las preferencias del sistema y evitar que una mejora estética dificulte el uso de la interfaz.
Cuándo merece la pena utilizar View Transitions
La API resulta especialmente interesante en aplicaciones donde existe una relación visual clara entre dos estados: una tarjeta que se convierte en detalle, un listado que cambia de orden, una galería, una navegación entre secciones o un panel que se abre y se cierra.
También puede ser útil en webs multipágina que quieren mejorar la sensación de continuidad sin incorporar un sistema de navegación cliente.
En cambio, no tiene demasiado sentido introducir transiciones en todos los cambios de estado por el simple hecho de que sea posible. Las animaciones excesivas pueden ralentizar la percepción de la interfaz, distraer y hacer que una aplicación de gestión resulte menos eficiente.
Para aplicaciones empresariales, la prioridad suele ser que las acciones sean rápidas, previsibles y claras. Una transición breve puede ayudar a comprender un cambio de contexto, pero una animación larga cada vez que se abre un formulario probablemente empeorará la experiencia.
Qué aporta realmente al desarrollo web moderno
View Transitions es un ejemplo de cómo la plataforma web continúa incorporando capacidades que antes dependían de soluciones externas. No elimina la necesidad de frameworks ni convierte las aplicaciones tradicionales en obsoletas, pero amplía las opciones disponibles.
El desarrollador puede elegir una arquitectura SPA, MPA o híbrida por sus necesidades reales de estado, renderizado, SEO y mantenimiento, en lugar de hacerlo únicamente por la experiencia visual que desea conseguir.
Ese es el cambio importante: las transiciones dejan de ser una característica asociada a una arquitectura concreta y pasan a formar parte de las capacidades del navegador.
Conclusión
La evolución de View Transitions API demuestra que no todas las mejoras del desarrollo web llegan mediante nuevos frameworks o herramientas de inteligencia artificial. A veces, la innovación consiste en trasladar una responsabilidad al navegador y simplificar el código que necesitamos mantener.
Para proyectos nuevos, merece la pena conocer esta API antes de incorporar dependencias de animación. Para proyectos existentes, puede ser una oportunidad de mejorar determinadas interacciones sin modificar toda la arquitectura.
La recomendación es utilizarla de forma progresiva: comenzar con transiciones sencillas, comprobar la compatibilidad de las funcionalidades necesarias y mantener siempre la navegación y los cambios de estado operativos sin animación.
El objetivo no es que una web tenga más movimiento, sino que el usuario comprenda mejor lo que está ocurriendo mientras la aplicación sigue siendo rápida, accesible y mantenible.