¿Qué es Next.js? Guía para principiantes

¿Qué es Next.js? (en palabras simples)

Next.js es un framework basado en React y Node.js que facilita crear aplicaciones web modernas (overview). Te da un stack full‑stack en un solo repo: páginas frontend, endpoints backend y opciones de renderizado como SSR y SSG listas para usar. Por eso es popular para SaaS: buen rendimiento, SEO amigable y APIs en el mismo código (why developers use Next.js).

Lo que Next.js trae de serie

Routing basado en archivos

• Las rutas se generan desde tu estructura de archivos (file-based routing).
• Ejemplo: pages/about.js se convierte en /about.

Server-Side Rendering (SSR)

• Las páginas pueden renderizarse en el servidor por request (SSR basics).
• Mejora el primer render y el SEO. React hidrata en el cliente.

Static Site Generation (SSG)

• Las páginas se preconstruyen en build time (SSG).
• Ideal para marketing y docs que cambian poco.

API Routes integradas

• Endpoints backend en el mismo repo (API routes).
• No necesitas un servidor aparte al empezar.

Code splitting y optimización automática

• Cada página carga solo el JS/CSS que necesita (optimizations).
• Minificación, tree‑shaking e imágenes optimizadas ya vienen incluidos.

DX sin configuración

• Soporte nativo para TypeScript, CSS y Sass.
• Puedes enfocarte en el producto, no en la configuración (DX overview).

Routing y layouts en Next.js

Next.js mapea carpetas y archivos a URLs automáticamente. Un archivo como pages/user/settings/notifications.js se convierte en /user/settings/notifications. Las rutas dinámicas funcionan igual: [id].js en pages/posts/ mapea a /posts/123.

También soporta layouts reutilizables. Con App Router puedes definir layouts anidados por carpeta (por ejemplo app/dashboard/layout.js), y todas las páginas bajo /dashboard/* lo heredan (nested layouts). Es perfecto para SaaS con sitio público y dashboard con UI distinta.

Server Components vs Client Components (simple)

Next.js (sobre todo 13+) distingue dónde corre un componente:

Server Components

• Renderizan en el servidor y envían HTML al navegador.
• No se envía JS al cliente (server vs client components).
• Ideales para render rápido y datos sensibles.

Client Components

• Corren en el navegador y permiten interactividad.
• Requieren la directiva "use client" al inicio del archivo (client components).
• Necesarios para clicks, formularios, gráficos, animaciones, etc.

En la práctica, las páginas mezclan ambos: server components para estructura/datos, client components para widgets interactivos. Así obtienes velocidad y buena UX.

API Routes integradas: backend en el mismo repo

Next.js permite crear endpoints junto al UI. Cualquier archivo en pages/api/ (Pages Router) o app/api/ (App Router) se convierte en un endpoint HTTP. Ejemplo:

// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ greeting: "Hello from Next API" });
}

Al pedir /api/hello, el código se ejecuta en el servidor y devuelve JSON. En Vercel, estas rutas se convierten en funciones serverless. El código en pages/api no se envía al navegador (API routes are server-only), así que puedes guardar secretos y conectar a tu DB con seguridad.

Ejercicio rápido: ejecuta pnpm dev y visita http://localhost:3000/api/health (después de crear api/health). Si ves { "status": "ok" }, tu frontend y backend están en la misma app.

Por eso muchos equipos empiezan con un solo repo Next.js: UI y API sincronizados, sin CORS, y tipos compartidos. Si más adelante necesitas un backend dedicado, puedes añadirlo y seguir usando Next.js para el frontend. No es todo o nada.

Tradeoffs: cuándo podrías no necesitar Next.js

Next.js es potente, pero no obligatorio:

• Sitios muy simples: una landing estática puede ser más sencilla con HTML o Vite. Next.js puede sentirse excesivo en proyectos mínimos, aunque escala bien (is it overkill?).
• Backend ya existente: si solo necesitas UI cliente y no te importa SSR/SEO, un React más ligero puede bastar. Aun así, Next.js sigue siendo válido si quieres convenciones.
• Backends especializados: para procesamiento pesado, microservicios o varios frontends compartiendo API, podrías usar un backend separado y Next.js como UI (separate backend?).

Aun así, muchos SaaS empiezan y crecen solo con Next.js. Por ejemplo, sushi-templates.com usa Next.js en todo el stack. El framework te da un flujo full‑stack y te deja integrar servicios externos solo cuando hace falta (why it’s a game-changer).

Conclusión y siguientes pasos

Next.js ofrece una forma potente y accesible de construir apps web. Simplifica el routing, el renderizado y los endpoints backend en un mismo código, para que te concentres en el producto.

Si quieres probarlo:

1. Crea un proyecto con npx create-next-app@latest o un template.
2. Ejecuta pnpm dev.
3. Agrega una ruta api/health y abre http://localhost:3000/api/health.

Desde ahí, crea páginas con routing por archivos, usa server components para datos rápidos y client components para interactividad. Next.js se encarga del resto.

Referencias

• Contentful Blog – Next.js vs React: https://www.contentful.com/blog/next-js-vs-react/
• Dev.to – Next.js overview and tradeoffs: https://dev.to/hamzakhan/why-nextjs-is-an-all-time-game-changer-for-web-development-a-technical-perspective-1bgf
• Reddit r/nextjs discussion (features): https://www.reddit.com/r/nextjs/comments/v01uy1/why_should_i_use_next_other_than_ssr/
• Stack Overflow – Next vs separate backend: https://stackoverflow.com/questions/78349307/ssr-and-api-layer-in-nextjs
• LogRocket – Next.js layouts: https://blog.logrocket.com/guide-next-js-layouts-nested-layouts/
• Dev.to – Server vs client components: https://dev.to/oskarinmix/server-components-vs-client-components-in-nextjs-differences-pros-and-cons-389f