View Transitions in Next.js 15: Retire Framer Motion?

What View Transitions Do

The browser captures a snapshot of the current DOM, applies your state change, captures the new DOM, and cross-fades between them with optional CSS-animated bits. Elements that share a view-transition-name between old and new snapshots get a dedicated transition group. Enabling shared-element animations (hero image morphing from a grid thumbnail to a detail view, for example) with no JavaScript animation work.

Where View Transitions Beat Framer Motion

• Page transitions. Navigation between routes is the canonical use case. Next.js 15's App Router runs your state change inside a view transition automatically when experimental.viewTransition is enabled.
• Shared-element transitions. Hero images, card-to-detail morphs. Previously required carefully choreographed Framer Motion code; now a CSS name is enough.
• List re-orderings. Sorting, filtering, and reordering lists. The browser animates positions natively.
• Bundle size. Replacing Framer Motion for navigation-scale transitions can shave tens of kilobytes.

Where Framer Motion Still Wins

• Gesture-driven animation. Drag, pan, pinch, spring physics. View Transitions have no gesture story.
• Interruptible animations. If an animation can be re-targeted mid-flight by the next user input, Framer Motion's state management wins decisively.
• Complex orchestration. Stagger children, coordinate multiple independent timelines, respond to physics-adjacent rules.
• Scroll-driven effects. Scroll animations, parallax, scroll-linked state. Native CSS helps here, but Framer Motion is still more ergonomic.

The Simple Pattern: Route-Level View Transition

// next.config.ts
export default {
  experimental: { viewTransition: true },
};

// app/globals.css — tasteful default
::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 180ms;
  animation-timing-function: cubic-bezier(0.22, 0.61, 0.36, 1);
}

/* Opt specific elements into shared transitions */
.hero-image {
  view-transition-name: hero;
}

Shared-Element Transitions Across Routes

// On a list page
<Link href={`/products/${p.slug}`}>
  <img src={p.image} alt={p.name}
       style={{ viewTransitionName: `product-${p.id}` }} />
  <h3>{p.name}</h3>
</Link>

// On the detail page — same view-transition-name ties the elements together
<img src={product.image} alt={product.name}
     style={{ viewTransitionName: `product-${product.id}` }} />

// The browser morphs the image from grid cell to detail hero automatically.

The ViewTransition React 19 Primitive

React 19 exposes a ViewTransition component that wraps children and coordinates transitions with React's concurrent rendering. It is the right tool when state transitions happen via React's own updates (a list filter, a tab switch) rather than route navigation. Used together with Next.js's route-level support, the two cover the common transition patterns without reaching for a library.

Performance. Native Is Not Free

View Transitions do real work. The browser takes snapshots, which can thrash paint timing on large pages. On low-end mobile, poorly scoped transitions can feel worse than the pre-animation state. The mitigations are the same as for any CSS animation: keep view-transition-name on a small number of elements, avoid animating layout-heavy properties, and test on the devices your users actually have.

The Practical Rule

• Routes, shared elements, list re-ordering. View Transitions. The bundle savings are real and the API is tight.
• Gestures, physics, interruptible animations. Keep Framer Motion. No native equivalent in 2026.
• Complex dashboards with dozens of animated states. Hybrid. Native for the navigation layer, library for the interactive surface.

"Retire Framer Motion" is the wrong framing. "Scope it down to what it is uniquely good at" is the right one. Most Next.js applications can drop Framer Motion from the root bundle, load it only on the pages that need it, and let the browser do the rest.