Next.js 13 and the shift to server components
Next.js 13's App Router introduces React Server Components to the mainstream. It's a fundamental shift in how I build - and it's taken some getting used to.
If you've been building with Next.js for any length of time, the 13.x release and its new App Router represent the biggest change to the framework since it first appeared. React Server Components are no longer an experiment, they're the default. And that means rethinking some fairly fundamental assumptions about how I structure applications.
The core idea is straightforward, and if you've worked with React before, it'll click quickly: components render on the server by default. They can fetch data directly, access the filesystem, talk to databases, all without shipping any JavaScript to the browser. Client-side interactivity is opt-in, marked explicitly with a 'use client' directive. In theory, this means smaller bundles, faster page loads, and a cleaner separation between what the server handles and what the browser handles.
The learning curve is real
In practice, and you'll find this yourself, the transition has been bumpy. I started moving an internal project to the App Router in December, and the mental model shift caught me. Years of muscle memory around useEffect, client-side data fetching, and state management patterns don't just evaporate. You find yourself reaching for useState in a server component and wondering why nothing works. The error messages, at least in the early releases, weren't always helpful in explaining what you'd done wrong.
The other challenge is the ecosystem. Many popular React libraries assume a client-side environment. Drop a component library into a server component and you'll hit errors about window being undefined, or hooks being called outside a client context. The workaround is wrapping things in client component boundaries, which works but feels inelegant until the ecosystem catches up.
Why it matters for client projects
Despite the rough edges, the direction is right. For the kind of content-heavy, CMS-driven sites I build for clients, server components are a natural fit. Most of a marketing site is static content, it doesn't need interactivity, it just needs to render HTML and send it to the browser. Server components let us do exactly that, with data fetching that's simpler and more performant than the getStaticProps/getServerSideProps pattern I've been using.
I'm running the App Router on a couple of non-critical projects right now, building confidence before I use it on client work. The caching behaviour in particular needs careful attention, it's powerful but opaque, and getting it wrong means serving stale content or hammering your CMS API unnecessarily.
For agencies and freelancers evaluating whether to adopt the App Router now or wait: if you're starting a new project and can tolerate some instability, it's worth learning on. If you've got a production Pages Router app that's working fine, there's no rush to migrate. Vercel has been clear that Pages Router isn't going anywhere.
I'll be writing more about specific patterns as I learn them. If you're working through the same transition and want to compare notes, get in touch, we're all figuring this out together.
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.