all posts
Mar 10, 2025·6 min read

Why Next.js is My Go-To Framework

Next.jsReactWeb Dev

After building dozens of projects with various frameworks - plain React, Vue, Svelte, even some forays into Remix and Astro - I keep coming back to Next.js. It's become my default choice for nearly everything I build, and I want to explain why. Not as a Next.js evangelist, but as someone who's genuinely tried the alternatives and found their way back.

The App Router Changed Everything

When Next.js 13 introduced the App Router, I was skeptical. The Pages Router worked fine. Why complicate things with a new mental model? Then I actually built something with it, and I understood.

Server Components fundamentally changed how I think about React applications. The simple fact that you can fetch data directly in your components, without useEffect or tangled state management, makes code dramatically cleaner. Components become self-contained units that declare what they need and render what they produce. No more prop drilling through layers of the tree just to pass data from an API call.

But the real magic is what users experience. Less JavaScript ships to the browser. Pages feel faster because they are faster. The amount of client-side JavaScript my applications send dropped by 40% just by using server components appropriately. Users on slow connections noticed immediately.

Nested layouts are another feature I didn't know I needed until I had it. The ability to share UI across routes while keeping each route's specific content isolated makes complex applications manageable. Navigation feels instant because the shared layout persists while only the changed content updates.

Full Stack in One Place

There's something deeply satisfying about having your entire application in a single codebase. API routes and server actions mean I can build complete applications without spinning up a separate backend service. For CareerWeave AI, my entire API surface lives in the same repository as my frontend. Deployment is a single command. Type safety flows from database to UI without any gaps.

This isn't about avoiding backends - it's about reducing unnecessary complexity. When I need a proper backend service, I build one. But for many applications, the backend is just shuffling data between a database and a frontend. Next.js handles that beautifully without the overhead of managing separate deployments, separate repositories, and separate mental contexts.

Server actions in particular feel like the future of form handling. Instead of creating API endpoints and wiring up fetch calls, you just... call a function. The function runs on the server. The types are checked at compile time. Errors are handled automatically. It's forms the way they should have been all along.

Developer Experience That Actually Matters

I'm suspicious of "developer experience" as a selling point because it often means "we made the wrong tradeoffs to make demos look good." Next.js isn't like that. The DX is excellent AND the production output is excellent.

Hot reloading works reliably. This sounds basic, but if you've ever fought with webpack configuration or watched your React state disappear on every save, you know it's not guaranteed. Next.js just works.

TypeScript is a first-class citizen without any configuration. I start a project, write TypeScript, and everything just flows. Imports autocomplete. Types check. Errors surface in my editor before I even save.

The error messages are actually helpful. When something goes wrong - and things always go wrong - Next.js tells me what happened in terms I can act on. Stack traces point to my code, not library internals. Suggestions point toward solutions.

Documentation deserves special mention. The Next.js docs are some of the best I've encountered in any technology. They're comprehensive without being overwhelming, with examples that actually match real-world usage patterns.

The Ecosystem Effect

Vercel's integration with Next.js is seamless to the point of being suspicious. One git push and my application is deployed, with preview URLs for every PR, automatic SSL, edge functions, image optimization, and analytics. The friction between "I finished coding" and "users can access my app" approaches zero.

But it's not just Vercel. The React ecosystem integrates naturally with Next.js. Auth libraries, database ORMs, component systems - they all assume you might be using Next.js and document accordingly. This network effect makes problem-solving faster because someone has probably encountered and documented your exact issue.

When I Reach For Something Else

Next.js isn't perfect for everything, and pretending otherwise would be dishonest. For purely static sites with no dynamic content, Astro's approach of shipping zero JavaScript by default is compelling. If I'm building a blog or marketing site, Astro often makes more sense.

For applications that need maximum flexibility in their routing or data patterns, Remix offers a different mental model that some projects benefit from. The loader/action pattern handles certain types of forms more elegantly than Next.js's approach.

And sometimes you just need a simple React app. Create React App is deprecated, but Vite serves the same purpose. For internal tools or quick prototypes where I know I'll never need SSR or API routes, spinning up a plain Vite + React project is faster and simpler.

But these are exceptions. For most applications - SaaS products, e-commerce sites, dashboards, portfolios, web apps with authentication and databases - Next.js is my starting point. The flexibility to add complexity when needed, combined with sensible defaults that handle common cases, makes it the framework I reach for by default.

The Honest Truth

No framework will make you a better developer. No technology choice will save a bad product. But given a good idea and the skills to execute it, Next.js removes friction between conception and creation in a way I haven't found elsewhere. That matters. Time not spent fighting tools is time spent building features users actually care about.