Swup Page Transition — Free Hooks-Driven Fade Transition Snippet

Swup animates real page-to-page navigation: it intercepts internal link clicks, fetches the destination page's HTML, and swaps its containers into the DOM while firing lifecycle hooks — visit:start, content:replace, visit:end — around the swap. It leans on CSS to own the actual animation: Swup toggles an is-transitioning class and waits for the CSS transition-duration on that class before continuing, rather than animating with JavaScript directly. This snippet is a single HTML document with nothing to fetch, so it adapts that exact hooks-and-class pattern onto two containers already present in the page.

What's real Swup and what's adapted

new Swup({ containers: [...] }), the swup.hooks.on(...) subscriptions, and the transition-fade / is-transitioning class convention are exactly how Swup is used in production — that class-toggle timing model is Swup's actual design, not a simplification. What's adapted is the trigger: since there's no second URL to fetch, a click handler calls swup.hooks.call(...) at the same points Swup's own router would, and toggles hidden/is-transitioning on the two sibling containers instead of Swup replacing fetched content. Drop this onto a real multi-page site and you'd delete the manual toggling — Swup's router calls the hooks and swaps content itself.

CSS owns the timing, not JavaScript

Unlike a JS-driven tween, Swup's convention is to add a class and let the browser's own transition property determine how long the animation takes; Swup (and this adaptation) just waits that same duration before proceeding. That's why .transition-fade defines the opacity/transform transition and .is-transitioning defines the "leaving" state entirely in CSS — change the transition timing function or duration in one place and the whole visit lifecycle respects it automatically.

The hook sequence

visit:start fires as a visit begins (here, on click); content:replace fires the moment the new content is swapped in (here, when the next container is un-hidden); visit:end fires once the entering transition finishes. Subscribing via swup.hooks.on is how you'd hang a loading bar, analytics ping, or scroll-reset off any point in a real Swup-powered navigation.

Where this fits

For the same navigation-transition problem solved with a different library and a transitions-array hook shape instead of an event emitter, see Barba.js page transition. For scroll-triggered rather than navigation-triggered motion, see scroll reveal grid.

Customizing it

Add more containers, change .is-transitioning's transform for a different exit direction, or hang extra behavior off content:replace (like resetting scroll position, which real Swup does by default). In production, Swup's containers option targets CSS selectors present on both the current and fetched page, so naming them consistently across templates is what makes the swap work at all.