Why Next.js is my favorite framework

A framework you choose, not one you settle for

There are tools you use because you don't really have a choice, and there are tools you genuinely choose, with conviction. Next.js falls into that second category for me. It's not just "React with routing bolted on": over the course of many projects, it has become the way I think about building a site, from rendering all the way to performance.

This portfolio I just redesigned? Built with Next.js, of course. And on every project, the reason is always the same: it lets me move fast without ever feeling boxed in.

Rendering, finally flexible

What convinced me at first was the freedom to choose how a page should be rendered. Depending on the need, I can use Server-Side Rendering for content that changes often, Static Site Generation for pages that don't need to regenerate on every request, or even mix both within a single application.

Before, this kind of choice often meant switching tools, or even the entire architecture. With Next.js, it's a decision made at the page level, almost at the component level since the App Router arrived. This flexibility completely changes how you approach a project: you're no longer building "a static site" or "a dynamic app," you're simply building the right rendering strategy in the right place.

Server Components, a real paradigm shift

React Server Components are probably what struck me the most in frontend development over the past few years. Being able to write components that run on the server, that access a database or an API directly without exposing a dedicated endpoint, without sending any JS bundle to the client, really changes the game in terms of performance.

The concrete result: less JavaScript shipped to the browser, pages that load faster, and code that's easier to reason about because you know exactly where each part runs. It takes a bit of an adjustment period at first, the time to really understand the boundary between server and client components, but once it clicks, you really don't want to go back.

A developer experience thought through to the end

Next.js is also a thousand small details that, added together, make a real difference day to day:

• File-based routing, simple and predictable.
• Automatic image optimization with the Image component, handling lazy loading and modern formats without complicated configuration.
• Near-instant hot reload in development.
• Natural integration with TypeScript, without friction.

These are things you could recreate yourself with other tools, but why reinvent the wheel when the framework already handles it, and handles it well?

An ecosystem that grows with your needs

What I also appreciate is that Next.js never tries to do everything its own way and only its own way. It integrates well with the existing ecosystem: Tailwind, Prisma, i18n libraries like next-international that I used on my portfolio, or various authentication solutions. You keep the freedom to compose your own stack, while still benefiting from a solid foundation.

And when it's time to deploy, the simplicity is there too. Whether on Vercel or elsewhere, moving from development to production happens without unpleasant surprises, which isn't always the case with other, younger or less mature frameworks on that front.

Why it matters, beyond the technical side

Deep down, what I really like about Next.js is that it lets me focus on what matters: the product, the user experience, the perceived performance. I spend less time fighting with configuration or reinventing mechanisms others have already solved, and more time on the details that make a site truly stand out.

A good tool isn't the one with the most features. It's the one that fades into the background to let the work shine. And that's exactly what Next.js does for me, project after project.