Sunny Tech 2025 : L'API viewTransition, une révolution pour le web ?
J’ai eu la chance de participer à la conférence Sunny Tech 2025 cette année à Montpellier, et l’une des annonces qui m’a le plus marqué concerne une nouveauté pour l’avenir du web frontend : l’API viewTransition. Cette session, animée par l’équipe web du Sunny Tech (voir la présentation officielle), a soulevé une question brûlante : l’API viewTransition va-t-elle révolutionner l’expérience utilisateur sur le web ?
L’enjeu : des transitions harmonieuses nativement 🌐✨
En tant que développeur fullstack, j’ai souvent jonglé avec les transitions d’une page à l’autre, notamment sur des applications React ou Next.js. Actuellement, la plupart des transitions animées entre vues nécessitent des librairies JavaScript externes, des hacks CSS, ou des architectures assez élaborées pour obtenir un rendu fluide – tout ça coûte souvent en complexité, en performance, et même parfois en accessibilité.
C’est dans ce contexte que l’API viewTransition débarque.
viewTransition, kézako ? 👀
L’API viewTransition a pour objectif de permettre aux développeurs web de réaliser facilement des transitions animées entre deux états visuels : navigation entre pages, changements de sections, ou même modifications profondes dans le DOM.
L’atout majeur ? C’est natif, c’est-à-dire pris en charge par le navigateur. Concrètement, on peut enfin imaginer des effets “crossfade” (fondu enchaîné), des déplacements d’éléments ou des zooms fluides de page à page, sans perdre en performance ni en accessibilité. Voici une introduction en vidéo :
Comment ça marche ? Quelques lignes suffisent 🤏
En pratique, il suffit de wrapper la mutation du DOM à travers la méthode startViewTransition, disponible désormais dans Chrome et Edge. Exemple très basique :
document.startViewTransition(() => {
main.innerHTML = '<h1>Nouveau contenu !</h1>';
});
Le navigateur capture l’avant/après et fait le reste, en laissant la main au développeur pour personnaliser la transition via CSS ou JavaScript. Si vous voulez tester, je vous encourage à jouer avec cette démo.
Ce que ça change pour mon métier 👨💻
En ayant travaillé sur des gros projets réactifs (SNCF, ABES, DomData), je vois un intérêt immédiat :
- Abandonner des solutions lourdes type React Transition Group ou des bridges JavaScript-CSS complexes,
- Moins de tech-debt, car on se repose sur le moteur du navigateur,
- Accessibilité améliorée — le rendu reste compatible native screen readers,
- Design System plus cohérent, en utilisant les mêmes transitions partout, et facilement personnalisables.
Dans une app Next.js ou React, il n’est plus utopique de rendre chaque changement de route doux, même dans des environnements avec SSR ou des contraintes server/client.
Limites et perspectives 👀
Attention : la spec évolue et tout n’est pas encore possible. Certaines animations complexes (ex : anim d’éléments entre containers différents) ne sont pas encore triviales. Et le support navigateur reste partiel. Mais le rythme d’adoption est impressionnant.
À surveiller particulièrement : l’arrivée sur Firefox. Les tests montrent déjà de vrais gains de performance et de simplicité sur Chrome Canary.