React & Next.js

Overview

React won the front end because component composition genuinely scales as an interface grows. Next.js added what React deliberately left out — routing, rendering strategy, data fetching and a build pipeline — and turned it into something you can put in production without assembling five libraries yourself.

The failure mode is well known: a single-page application that ships a large bundle, renders a blank screen until it hydrates, and performs badly on the mid-range Android phones most people actually use. Avoiding that is mostly about choosing the right rendering strategy per route rather than applying one to the entire site.

Choosing a rendering strategy

Next.js lets each route pick, and picking well is where most of the performance comes from.

• Static (SSG) for marketing pages, documentation and anything that changes on a deploy cadence. Served from the edge, effectively instant, and impossible to make slow.
• Incremental Static Regeneration for content that changes often but not per user — product listings, blog indexes, category pages. Static speed with fresh content, without rebuilding the whole site.
• Server-side rendering where the page depends on the request: personalised dashboards, authenticated views, anything with per-user data that also needs to be indexable or fast on first paint.
• Client rendering for genuinely interactive regions behind authentication, where SEO is irrelevant and interactivity is the whole point.

Most real projects use three of these in one application. Treating that as normal, rather than picking one and forcing everything through it, is the difference between a fast site and a slow one.

Server components and the App Router

React Server Components are the most significant change to React in years. Components that render on the server ship no JavaScript to the browser at all — data fetching, formatting and heavyweight libraries stay server-side, and only genuinely interactive pieces become client components.

In practice this removes a large amount of what used to bloat React bundles: date libraries, markdown parsers, syntax highlighters and data transformation code. We default to server components and mark client boundaries deliberately, keeping "use client" as far down the tree as possible.

Server Actions handle mutations without hand-written API endpoints for every form, with progressive enhancement so a form still submits if JavaScript has not loaded.

Performance

• Bundle analysis in CI with an enforced budget, so a heavy dependency is caught at review rather than in production.
• next/image for automatic responsive sizing, modern formats and lazy loading, with explicit dimensions so nothing shifts.
• next/font to self-host and preload fonts, removing a third-party connection from the critical path.
• Dynamic imports for heavy, rarely-used components — editors, charts, map widgets.
• Streaming with Suspense so the page renders progressively instead of waiting for the slowest query.
• Careful caching: request memoisation, the data cache and route caching each configured deliberately, because the defaults surprise people in both directions.

State and data

Most applications do not need a global state library. Server state — data that lives in your database — belongs in TanStack Query or the framework's own caching, which handle refetching, invalidation and stale data properly. Genuine client state is usually small and local; where it is shared, Zustand or Context is normally sufficient. We reach for Redux when the domain actually justifies it, which is less often than its popularity suggests.

End-to-end type safety matters here: TypeScript in strict mode, schema validation with Zod at the boundaries, and generated types from the API so a backend change surfaces as a compile error rather than a runtime crash.

Accessibility and SEO

A React application is not automatically accessible or indexable. We use semantic HTML rather than nested divs with click handlers, manage focus explicitly on route changes and in modals, keep keyboard navigation working throughout, and test with a screen reader. For SEO, server rendering plus proper metadata, canonical URLs and JSON-LD structured data per route.

Testing and maintainability

Vitest or Jest with React Testing Library for behaviour-focused component tests, Playwright for the critical user journeys, and type checking and linting as CI gates. We test what a user does, not implementation details, so tests survive refactoring instead of obstructing it.

How we work

1. Decide the rendering strategy per route before building, based on how the data actually behaves.
2. Set up strict TypeScript, linting, bundle budgets and preview deployments on day one.
3. Build server-first, adding client interactivity only where it is needed.
4. Measure Core Web Vitals on throttled mobile at every milestone.
5. Hand over with architecture documentation and a deployment runbook.

What you get

• A rendering strategy chosen per route and documented, not applied blindly.
• A measured, enforced JavaScript budget.
• Type safety from the database through to the component.
• Core Web Vitals inside Google's thresholds on real mobile hardware.
• Tests on the journeys that matter, running in CI.

The point of server components is not novelty. It is that the date formatting library your users were downloading never needed to leave the server.