React View Transitions: How to Use Them for Client Work

You just told a client their new site will "feel like an app." Then you open Framer Motion's docs to wire up a page transition for what is, underneath, three routes and a contact form.

That gap between the ask and the tooling isn't you overengineering. React view transitions just changed what's actually needed here. Browser-native page transitions didn't work well enough to ship until very recently. So the JS-library workaround became the default. It stuck around even after the reason for it went away.

Something changed on September 9, 2026. It's worth twenty minutes of your time this week.

What's Actually New in React 19.3

React 19.3 shipped on npm on September 9, 2026. The big change: <ViewTransition> moved out of experimental status. It's stable now. That signal usually matters more than the feature itself — React's team doesn't stabilize things it plans to rip out later.

<ViewTransition> wraps a piece of UI. It animates that UI through four moments: when it's added (enter), removed (exit), changed in place (update), or moved between two spots on the page (share, using a shared name). It runs on the browser's own View Transition API. It doesn't rebuild animation logic in JavaScript from scratch.

import { ViewTransition } from 'react';

{isShowing && (
  <ViewTransition>
    <Sidebar />
  </ViewTransition>
)}

That's the whole API for the simple case. No spring configs. No animation library import. No extra bundle weight.

A second feature stabilized in this same release. It solves a different problem — one that shows up more in dashboards and admin panels than on marketing sites.

Is React View Transitions Ready for Production Work?

This is the question that actually matters. As of this release, the honest answer went from "not quite" to "mostly, check your audience."

The underlying View Transition API now has 91.75% global browser support. Chrome and Edge have had it since version 111. Firefox added it at version 144. Safari — the usual holdout on APIs like this one — shipped support at version 18.0. Current Safari is well past that number.

That last piece is what changed things. A feature that only worked in Chrome wasn't something you could show a client and call finished. A feature that works in all four major browsers is.

Here's the part that makes it low-risk to adopt: unsupported browsers don't break. They just skip the animation. <ViewTransition> falls back to an instant state change on anything that doesn't understand the underlying API. No polyfill. No fallback code to write. You can ship it today, and the roughly 8% of visitors on an older browser simply see the old, non-animated behavior — not a broken page.

How to Add Your First React View Transition

Here's the version you'd actually use on a client project: animating a route change, with no routing-aware animation library required.

import { ViewTransition, startTransition } from 'react';

function Nav({ page, onNavigate }) {
  return (
    <ViewTransition>
      {page === 'home' ? <HomePage /> : <ProjectsPage />}
    </ViewTransition>
  );
}

function handleClick(nextPage) {
  startTransition(() => setPage(nextPage));
}

Wrap the swapped content in <ViewTransition>. Trigger the change inside startTransition. That's enough to get a cross-fade by default. From there, addTransitionType lets you pick a different animation based on why the change happened — a carousel moving forward gets a different motion than one moving back, using the same component.

For a shared element — say, a thumbnail that should grow into a detail view — give both instances the same name prop. React handles the handoff between positions on its own. This is the exact pattern most agencies used to pull in a JavaScript library just to build by hand.

That raises a real decision for every project after this one, and it's not really about which tool looks better in a demo.

React View Transitions vs. Framer Motion: Which Should You Use

Neither tool replaces the other. They solve different problems, and picking the wrong one costs you either bundle size or hours of your time.

The practical rule for client work: reach for <ViewTransition> first when something just changed state or position. Reach for Framer Motion when a client specifically wants drag interactions, spring-based bounce, or animation tied to scroll position — the things the View Transition API was never built to do.

Dropping a dependency saves more than kilobytes. It's one less package you have to keep patched on every project you hand off. That matters more than it sounds like once you're maintaining a dozen client codebases instead of one.

Fragment Refs and the browser() Function: The Rest of 19.3

Fragment refs are the second stable feature in this release. They fix a smaller but genuinely annoying problem: getting a ref on a group of sibling elements without wrapping them in an extra <div> just to attach one.

function PostList({ posts }) {
  const fragmentRef = useRef(null);

  useEffect(() => {
    fragmentRef.current.focus();
  }, []);

  return (
    <Fragment ref={fragmentRef}>
      {posts.map(post => <Heading key={post.id}>{post.title}</Heading>)}
    </Fragment>
  );
}

A FragmentInstance supports focus control, event listeners, and observers like IntersectionObserver across the whole group. That's useful for component libraries, where an extra wrapper <div> would break a client's existing CSS.

React 19.3 also shipped a browser() function for React DOM. It lets a component skip server rendering and show a Suspense fallback on the server only — handy for anything that needs Intl or another browser-only API during a server-rendered page. Server Components can now render Context directly too, with no wrapper-provider code needed.

None of these three is the headline. <ViewTransition> going stable is, because it's the one that shows up in a client demo. There's one more thing that matters once this actually ships to a client, though, and it has nothing to do with React at all.

Shipping the Animated Build

The transitions are wired up. The client says it feels right. The next step is the same one it's always been: you package the build and hand it over. If you're moving an existing client site onto a new framework version at the same time, Cursor's Projects feature for coordinating multi-step migrations is worth a look before you start that upgrade by hand.

That handoff moment is where a slicker frontend stops mattering, if the invoice never gets paid. Polish doesn't change your leverage after delivery. The terms of the delivery do. That's a separate problem from anything React ships, and it's worth having a real answer for it before the next project goes out the door.

Frequently Asked Questions

Is React's ViewTransition component the same as the browser's View Transition API?

No, but it's built directly on top of it. <ViewTransition> is React's wrapper around the browser's native View Transition API. It handles the DOM lifecycle and React state changes, so you don't call document.startViewTransition() by hand.

Do I need a polyfill to use React View Transitions in production?

No. <ViewTransition> falls back cleanly on browsers that don't support the underlying API. The state change still happens, it just isn't animated. Nothing breaks, and no fallback code is required.

Does React View Transitions work with React Native?

Not yet. As of the 19.3 release, <ViewTransition> only works in DOM environments, meaning the web. Support for React Native and other platforms is still in progress.

Should I replace Framer Motion with React's ViewTransition component?

Only for the cases it covers well: route changes, list reordering, and shared-element transitions. Framer Motion and similar libraries are still the better pick for gesture-driven interactions, physics-based animation, and complex sequencing — things the View Transition API isn't built to handle.

One Thing to Do This Week

Upgrade a test branch to React 19.3. Wrap one route transition in <ViewTransition>. Check it in Safari before you show a client anything. That's the whole evaluation — no library to install, no config to write.

The code you ship still needs the same protection it always did, once it leaves your machine. DevAegis encrypts the build you deliver and holds the key until the invoice clears. So a client's site — animated or not — only keeps running while they're a paying client. See how it works and what's included, or start with what to do when a client won't agree to pay upfront.