Why I Choose Next.js for Every Project

8 min read
nextjsreactframeworksfrontendarchitecture

"Is Next.js dead?" The question keeps appearing in my feed. Developers are writing "goodbye Next.js" posts. TanStack Start is gaining momentum as the alternative. The discourse suggests the framework is on its way out.

I've been using Next.js for years, including for enterprise clients at Planetary and indie products at Helsky Labs. Here's why I still choose it for every full-stack project in 2026—and when I don't.

The Current Landscape

Let's acknowledge the criticism upfront. The complaints aren't baseless:

  • Constant breaking changes between major versions
  • Vercel lock-in concerns as the framework evolves around their platform
  • App Router complexity that feels over-engineered for simple use cases
  • Server Components learning curve that trips up experienced React developers

I've experienced all of these. They're real friction points.

But here's what the "goodbye Next.js" posts often miss: the alternatives have their own friction. And for my specific needs—full-stack web apps with SSR, good SEO, and rapid iteration—Next.js still solves more problems than it creates.

What Next.js Actually Gives Me

Convention Over Configuration

This is the killer feature that rarely gets mentioned in comparison posts.

With Next.js, I don't decide:

  • Where routes live (file-based routing)
  • How to configure SSR vs. SSG vs. ISR (per-page options)
  • How to set up API routes (same file system)
  • How to handle environment variables (built-in patterns)
  • How to optimize images (next/image)
  • How to configure TypeScript (works out of the box)

Every decision I don't have to make is time saved. For a solo developer or small team, these conventions compound into significant velocity.

// This file IS the route, the data fetching, and the component
// No configuration, no wiring, no ceremony

// app/products/[id]/page.tsx
export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);
  return <ProductDetails product={product} />;
}

Server Components Work

Server Components were confusing at first. The mental model shift is real. But after building with them for over a year, I can't go back.

The pattern that changed my thinking:

// Before: Client component with useEffect data fetching
'use client';
export function ProductList() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/products')
      .then(r => r.json())
      .then(setProducts)
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <Spinner />;
  return <List items={products} />;
}

// After: Server Component with async/await
export async function ProductList() {
  const products = await db.products.findMany();
  return <List items={products} />;
}

The "after" version:

  • Ships less JavaScript to the client
  • Has no loading state (data fetched before render)
  • Can query the database directly
  • Is easier to read and maintain

For content-heavy sites—which describes most of what I build—this is transformative.

Turbopack is Finally Production-Ready

The skepticism about Turbopack was justified during the beta years. It wasn't ready.

In 2026, it is. Next.js 16 made Turbopack the default bundler, and the improvements are measurable:

  • Dev server starts in under 200ms (compared to 2-3 seconds with Webpack)
  • Hot Module Replacement is nearly instant
  • Production builds are 2-3x faster

For rapid iteration during 6-day sprints, these seconds add up.

The Deployment Story is Solved

Yes, Vercel lock-in is a concern. Yes, Next.js features land on Vercel first. But let's be practical: Vercel deployment just works.

git push origin main
# App is live 60 seconds later with:
# - Automatic HTTPS
# - Global CDN
# - Preview deployments for every PR
# - Zero configuration

I can deploy to other platforms (Netlify, Railway, self-hosted), but why? The Vercel free tier handles everything I need for indie projects. For enterprise clients, the pricing is justified by the saved DevOps time.

The "lock-in" concern is overblown for most use cases. If Vercel's pricing becomes untenable, migrating to a self-hosted Next.js deployment is well-documented.

The Honest Alternatives Comparison

TanStack Start

TanStack Start is the most interesting alternative right now. Created by Tanner Linsley (TanStack Query, TanStack Router), it has strong ergonomics and excellent TypeScript support.

What TanStack Start does better:

  • Type-safe routing with zero code generation
  • Explicit data loading patterns (no magic)
  • Server functions without "use server" mental overhead
  • No Vercel dependency

Why I still choose Next.js:

  • Less mature ecosystem (started in 2024)
  • Fewer deployment platform options with first-class support
  • I already know Next.js patterns deeply
  • The "magic" I get from conventions saves time

For new projects where type-safety is paramount and you want to avoid Server Components entirely, TanStack Start is worth considering.

Astro

Astro wins for content-heavy sites. Period.

When I'd choose Astro over Next.js:

  • Marketing sites with minimal interactivity
  • Documentation sites
  • Blogs (yes, including this one in theory)

Why I still often choose Next.js:

  • Most projects need at least some interactivity
  • I don't want to context-switch between frameworks
  • Next.js handles content sites well enough

If I were building a pure content site from scratch, Astro's island architecture and 3x faster builds make it the better choice.

Vite + React

For pure single-page applications (SPAs) with no SEO requirements:

When Vite wins:

  • Internal dashboards
  • Apps behind authentication
  • Electron apps

When Next.js wins:

  • Public-facing pages that need SEO
  • Mixed auth/public content
  • Full-stack features (API routes, middleware)

Remix / React Router 7

Remix has excellent data handling patterns and a philosophy I respect. But the framework's trajectory has become unclear with the React Router merge. For new projects, I'd wait to see where it stabilizes.

When I Don't Choose Next.js

Being honest about limitations builds more credibility than blind advocacy.

I skip Next.js for:

  1. Mobile apps — React Native with Expo. Different paradigm entirely.

  2. Simple static sites — If there's no dynamic content and SEO is critical, Astro or even plain HTML with a static site generator.

  3. Highly interactive apps — For apps that are essentially SPAs (think Figma, Linear), the SSR overhead isn't worth it. Plain React with Vite.

  4. Serverless edge requirements — If I need to run complex logic at the edge with minimal cold starts, Next.js middleware has limitations. Consider alternatives like Cloudflare Workers.

  5. Teams that don't know React — If the team knows Vue or Svelte, don't force Next.js. Use Nuxt or SvelteKit.

My Standard Next.js Setup

For reference, here's how I start every Next.js project:

# Create project
npx create-next-app@latest my-project --typescript --tailwind --app

# Essential additions
npm install @tanstack/react-query    # Server state management
npm install zod                       # Runtime validation
npm install lucide-react              # Icons

Key configuration choices:

app/layout.tsx — Minimal root layout with Tailwind and providers app/api/ — API routes colocated with related features components/ — Shared UI components lib/ — Utilities, database clients, shared logic

The structure stays simple. Complex project structures usually mean the project scope crept.

The Real Reason

If I'm being fully honest, there's a simpler reason I choose Next.js: I know it.

I've built dozens of projects with Next.js. I know the gotchas. I know which abstractions leak. I know how to debug the weird edge cases.

Switching to TanStack Start or another framework means:

  • Learning new patterns
  • Discovering new edge cases
  • Building new mental models
  • Slower shipping while ramping up

For side projects and indie products where speed matters, familiarity compounds.

This isn't "Next.js is objectively best." It's "Next.js is best for me, right now, given my experience and use cases."

The Verdict for 2026

Next.js isn't dead. It isn't even declining. The framework continues to evolve, the ecosystem remains strong, and the Vercel team keeps shipping.

But it's also not the only choice anymore. The React framework landscape has matured. TanStack Start, Astro, and Vite are all excellent tools for specific use cases.

My approach:

  • Full-stack web app with SEO needs → Next.js
  • Content-heavy marketing site → Astro
  • Internal dashboard / SPA → Vite + React
  • Type-safety critical, anti-magic preference → TanStack Start
  • Mobile → React Native + Expo

The "best framework" question has no universal answer. The right answer is: what lets you ship fastest given what you're building and what you know?

For me, in 2026, that's still Next.js.

Questions about framework choices or Next.js architecture? I'm always happy to discuss the tradeoffs. Find me on GitHub or LinkedIn.