Blog/Web

Why I Bet My Stack on Next.js

I've written production code in PHP, vanilla JS, a dozen frameworks and back again. These days, when a new project starts, the default answer is Next.js — and it takes a very good reason to override that default.

One mental model, server to client

Server Components let me keep data-fetching close to the database while still shipping a rich client experience. I stopped maintaining two mental models for "the backend" and "the frontend".

The performance is in the defaults

Image optimisation, code splitting, streaming — the fast path is the default path. For a small team that matters more than any single feature.

  • App Router for clean, nested layouts.
  • Server Components to keep bundles small.
  • Edge-ready when latency actually matters.

Where it still hurts

The framework moves fast, and "fast" sometimes means churn. I pin versions, read the upgrade notes, and keep my abstractions thin so a migration is a weekend, not a quarter.

No framework is forever. But for the kind of products I build, Next.js currently buys the most leverage per line of code.

Back to all articlesWork with me