I spent last weekend migrating a client's application from Create React App to Next.js. What started as a simple performance optimisation turned into a revelation about how much unnecessary complexity we've been accepting. The site went from a 68 Lighthouse score to 94. The bundle size dropped by 40%. Time to interactive improved by 2.3 seconds. But the real win was deleting hundreds of lines of configuration and boilerplate.
This isn't my first Next.js rodeo. I've built everything from simple marketing sites to complex SaaS applications with it. Each project reinforced the same conclusion: Next.js makes the right decisions by default, letting you focus on building rather than configuring.
The framework wars have become background noise in web development. Every month brings a new "Next.js killer" promising better performance or developer experience. I've tried most of them. Some have interesting ideas. None have convinced me to switch. Not because Next.js is perfect, but because it consistently solves real problems without creating new ones.
Take routing. Every React developer has wrestled with React Router. Routes defined in JavaScript, nested configurations, protected route patterns copied from Stack Overflow. Next.js threw all that away. Your file system is your router. Create a file at app/about/page.tsx and you have an /about route. It's so obvious in hindsight that you wonder why we ever did it differently.
But file-based routing only works if it's flexible enough for real applications. Dynamic routes? Use brackets: [slug].tsx. Catch-all routes? [...segments].tsx. Nested layouts? Just add layout.tsx files. Every pattern I've needed has a simple, discoverable solution. No documentation diving required.
The real power shows when you start mixing rendering strategies. That's where Next.js leaves other frameworks behind. Your homepage can be statically generated for instant loading. Your dashboard can use server-side rendering for fresh data. Your interactive components can load on the client. All in the same application, often on the same page, without configuration gymnastics.
I recently built an e-commerce site that demonstrates this perfectly. Product listing pages are statically generated at build time - they load instantly and rank well in search engines. Individual product pages use incremental static regeneration, updating every hour to reflect inventory changes. The shopping cart is fully client-side for instant interactions. The checkout flow is server-rendered for security and progressive enhancement. Four different rendering strategies, zero configuration headaches.
Server components changed everything. I was sceptical at first - we've been here before with PHP and Rails. But server components aren't a return to old patterns. They're a recognition that the network boundary is the wrong place to split your application. With server components, you write React normally and let the framework figure out what runs where.
The performance improvements are staggering. Components that fetch data run on the server, sending only rendered HTML. No loading spinners, no waterfall requests, no client-side data fetching libraries. A typical page went from downloading 150KB of JavaScript to 40KB. Users on slow connections noticed immediately.
But performance is just part of the story. The developer experience is what keeps me coming back. Fast Refresh means changes appear instantly, preserving component state. When errors happen, the error overlay shows exactly what went wrong with suggestions for fixing it. TypeScript works out of the box with proper types for all Next.js APIs.
The ecosystem integration is thoughtful too. Need authentication? NextAuth.js integrates seamlessly. Want a CMS? Every major provider has Next.js examples. Database? Prisma, Drizzle, or any ORM works great. Styling? CSS Modules, Tailwind, or CSS-in-JS all have first-class support. You're never fighting the framework to use your preferred tools.
Image optimisation alone justifies using Next.js for content-heavy sites. The Image component automatically serves WebP or AVIF to supported browsers, resizes based on device, lazy loads with blur placeholders, and prevents layout shift. What used to require a CDN service and careful implementation now happens automatically.
I've built the same features in vanilla React. It takes weeks and never works as well. Lazy loading libraries conflict with each other. Route-based code splitting requires webpack configuration. SEO means wrestling with React Helmet. Data fetching patterns lead to prop drilling or complex state management. Next.js solved these problems so thoroughly that I forgot they existed.
The deployment story is equally compelling. Vercel makes it one-click, but Next.js runs anywhere Node.js does. I've deployed to AWS, Google Cloud, traditional VPS servers, even Docker containers. The build output is just a Node application. No vendor lock-in, no proprietary runtime.
Critics point to the learning curve. Server components are conceptually different. The app directory introduced new patterns. Fair points. But compare that to learning webpack configuration, choosing a router, setting up SSR from scratch, implementing code splitting, optimising images, configuring TypeScript, and solving the dozen other problems Next.js handles automatically. The framework's opinions save more time than they cost.
The stability matters too. Next.js is backed by Vercel, a company whose business model aligns with the framework's success. Updates are thoughtful, migrations are documented, and breaking changes are rare. I've upgraded major versions with minimal pain. Try that with a hand-rolled webpack configuration.
After five years and dozens of projects, patterns emerge. Marketing sites that need SEO and performance. Applications that benefit from server-side rendering. Blogs that want static generation with dynamic elements. E-commerce sites balancing static content with real-time data. Every time, Next.js provides a solid foundation without forcing architectural decisions.
Is it perfect? No. The app directory migration was rocky. Server components have edge cases. Build times for large static sites can be painful. Some patterns that were simple in pages directory became complex in app directory. But these are solvable problems in an otherwise excellent framework.
The question isn't whether Next.js is the best framework - that's subjective and depends on your needs. The question is whether it provides good defaults, solves real problems, and lets you focus on building. In my experience, consistently yes.
I still explore new frameworks. Solid Start looks promising. Remix has great ideas. Astro excels for content sites. But when a client needs a production application next month, I reach for Next.js. Not from laziness or familiarity, but because I know it will handle whatever requirements emerge without requiring architectural rewrites.
That's the ultimate test of a framework: can you build with confidence knowing it won't constrain you later? Next.js passes that test project after project. It's not exciting anymore. It's not the new hotness. It's just a reliable tool that solves more problems than it creates.
In web development, that's rarer than it should be.