Next.js 13.4 and the stable App Router: what really changes

Vercel marked the App Router stable in 13.4. Between Server Components, nested layouts and new routing conventions, here is what to adopt now and what to let mature.

On May 4, 2023, Vercel announced Next.js 13.4 and marked the App Router as stable for the first time. For anyone building web applications in a business setting it is a meaningful release: the model to build new projects on is now official, even though migrating existing pages/ apps remains a decision to weigh carefully.

What makes the App Router different

The headline change is not the new app/ folder but the adoption of React Server Components as the default. Every component runs on the server unless you explicitly opt out with "use client". This reshapes how we think about state, caching and data fetching: no more getServerSideProps, no more useEffect for first-load data.

Nested layouts and persistent UI

The layout.tsx in each directory becomes a persistent layout that does not unmount on navigation. For anyone with a sidebar, a topbar or a playback state, this is the difference between a real web app and a site that reloads everything on every click.

Streaming and Suspense

The App Router embraces HTTP streaming: the page arrives at the browser progressively, with ready blocks shown immediately and slow blocks handled by <Suspense>. For teams tracking Core Web Vitals it is a paradigm shift: TTFB drops, LCP stabilises, and perceived performance improves even on slow connections.

What we decided at SEM Devs

For new projects we adopt the App Router as the default from day one. For existing ones we do the opposite: no forced migration. Coexistence between pages/ and app/ in the same project is supported, and the App Router only makes sense when a new feature or a refactor calls for it.

Three things to watch

Aggressive caching: fetch is cached by default. Dynamic data needs explicit directives (cache: "no-store" or revalidate).
Server Actions still alpha: nice to experiment with, but in production we stick to API routes until they are stable.
Client-only libraries: some dependencies (date pickers, charting) require explicit "use client" boundaries, and this adds bundle weight.

Is it worth jumping in?

Yes, but with a plan. For the SMEs we work with the App Router means faster pages, less JavaScript shipped to the browser, and a mental model closer to the backend. It also means a learning curve, especially for teams used to Redux and client-side fetching. Our recommendation: start with new projects, let existing ones mature, and get ready for Next.js 14, where today's promises will become foundations.