We broke accessibility. Screen readers that worked perfectly with server-rendered pages now had to contend with JavaScript-mutated DOMs, focus management nightmares, and route changes that announced nothing. We broke SEO. Google had to build a headless Chrome renderer just to index SPA content, and for years, sites that relied on client-side rendering ranked lower simply because the crawler could not see the content.
We broke the browser's loading indicator. Users no longer knew whether a page was loading or frozen. So we built skeleton screens to simulate the loading indicator we had removed. Marvellous.
All so a heading could slide.
What It Replaces
The View Transition API does not replace everything. Framer Motion and GSAP remain valuable for complex interactive animations: drag-and-drop, spring physics, gesture-driven sequences. Those are runtime interactions, not page transitions. The distinction matters.
But for page-to-page navigation transitions? The use case that justified SPAs for millions of websites that are, fundamentally, collections of pages linked together with anchor tags?
| Solution |
Size |
JavaScript Required |
Works Without JS |
| Barba.js |
7.5KB min |
Yes |
No |
| Framer Motion |
32KB min |
Yes (React) |
No |
| SPA router |
Entire framework |
Yes |
No |
| View Transition API |
0KB |
No |
Graceful fallback |
Zero kilobytes. Because it is the browser. The runtime you already shipped.
Browser Support
Here is where honesty matters, and where many articles about this API get rather conveniently vague.
Full cross-document support:
- Chrome 126+ (desktop and Android)
- Edge 126+
- Safari 18.2+ (including iOS Safari)
- Opera 112+
- Samsung Internet 29+
Partial or no cross-document support:
- Firefox 146+: supports same-document view transitions (Level 1), but cross-document transitions remain behind a flag (
dom.viewTransitions.enabled in Nightly only as of April 2026)
- Opera Mini, KaiOS Browser, UC Browser: no support
Global coverage: 87.82% of users (CanIUse, April 2026). That is high, but it is not universal. Firefox's absence from the cross-document specification is notable, and for teams whose audience includes a significant Firefox share, this is a legitimate consideration.
Why it does not matter as much as you think:
For browsers that do not support the API: nothing breaks. The user sees a normal page load. No error. No fallback code. No polyfill. No broken layout. No JavaScript exception. The page loads exactly as it would have loaded before the API existed.
This is progressive enhancement in its purest form. The enhanced experience is literally free for supporting browsers (no additional bytes shipped), and the baseline experience is what every user had before. You are not degrading the experience for unsupported browsers. You are enhancing it for supported ones. The risk is zero. The cost is three lines of CSS.
One does rather appreciate an API that fails by doing nothing wrong.
Compare this with the SPA approach: if your JavaScript bundle fails to load (network timeout, CDN outage, ad blocker, corporate proxy), your users see a blank white page. The "enhanced" experience degrades to nothing. The View Transition API degrades to a normal page load. One does note the asymmetry.
The Constraints
Same-origin only. Cross-document view transitions work for same-origin navigations only. You cannot animate a transition from your site to an external URL. This is a security constraint, not a limitation: the browser needs access to both documents to snapshot them. If your site links to external domains, those navigations simply behave normally.
Unique names per page. Each view-transition-name must be unique within a single document. Two elements on the same page cannot share a name. This is rarely a problem in practice, but it means you cannot, for example, animate all list items with the same name. Each needs its own.
Performance consideration. The browser captures raster screenshots of named elements. Naming dozens of elements on a complex page could impact transition performance. In practice, naming three to five key elements (header, hero image, navigation, main content area) produces smooth results. Naming everything is rather missing the point of selective enhancement.
No cross-origin. Worth stating twice. If your architecture relies on navigating between subdomains (app.example.com to docs.example.com), these are cross-origin navigations and will not trigger view transitions. The same-origin policy applies strictly.
Same-Document Transitions
For single-page applications, the same-document View Transition API (available since Chrome 111, Safari 18+, Firefox 133+) provides equivalent functionality using document.startViewTransition(). This variant has broader browser support because it landed earlier.
But the cross-document variant is the interesting one, because it means multi-page applications, the architecture the web was built for, can now match the perceived smoothness of SPAs. Without being SPAs. Without the JavaScript. Without the complexity. Without breaking the back button, the cache, the loading indicator, accessibility, SEO, or the fundamental contract between browser and server.
The Point
For a decade, "smooth page transitions" was the argument that justified client-side routing, framework adoption, and the entire SPA architecture for websites that were, at their core, pages linked together with anchor tags. The browser lacked the capability, so we built it in JavaScript. Reasonably enough.
The browser has the capability now. Three lines of CSS. Zero JavaScript. Progressive enhancement built in. 87.82% global support and climbing. Firefox is the last holdout for cross-document, and the same-document variant already works there.
The argument no longer applies. The question is no longer "should we use an SPA for transitions?" The question is: "what were the other reasons?" One does suspect the list is rather shorter than expected.
One does wonder how many SPAs will be reconsidered. One does rather suspect the answer is: not enough.
Read the full article on vivianvoss.net →
By Vivian Voss — System Architect & Software Developer. Follow me on LinkedIn for daily technical writing.