Por: Braian de Barros, developer en Urudata Software
React cambió la forma de construir interfaces, pero dejó sin resolver problemas clave como el routing, el rendering del servidor y el SEO. Next.js llena esos vacíos. En la última edición de las Tech Talks de Urudata Software se presentó una charla donde desglosamos el framework, analizamos sus conceptos centrales y lo comparamos con otras alternativas del ecosistema.
¿Qué problema resuelve Next.js?
Para entender Next.js hay que entender primero de dónde viene. React dominó el desarrollo frontend durante años, y con razón: su modelo de componentes y su ecosistema son enormes. Pero React por sí solo resuelve solo una parte del problema. Se encarga de la vista, de cómo se construyen y actualizan los componentes en pantalla, pero deja afuera todo lo demás: cómo se navega entre páginas, cómo se obtienen los datos, cómo se optimiza la carga inicial y cómo se carga el contenido desde el servidor.
Una aplicación en React clásica corre completamente en el navegador: el servidor entrega una página prácticamente vacía (un <div> y un archivo JavaScript) y es el browser del usuario el que se encarga de construir toda la interfaz. Eso genera dos problemas concretos:
- SEO deficiente: cuando Google o cualquier motor de búsqueda intenta indexar la página, encuentra ese HTML vacío. El contenido existe recién después de que JavaScript se ejecuta, lo cual muchos crawlers no hacen o hacen parcialmente.
- Carga inicial lenta: el usuario ve una pantalla en blanco hasta que el navegador descarga, parsea y ejecuta todo el JavaScript necesario. En aplicaciones grandes con muchas dependencias, eso puede significar varios segundos de espera.
Next.js, creado por Vercel en 2016, nació para resolver exactamente eso. No reemplaza a React sino que lo extiende: agrega routing, rendering del lado del servidor, data fetching, optimizaciones de performance y capacidades de backend, todo integrado y con convenciones claras. Hoy tiene más del doble de descargas semanales que Angular y se convirtió en el estándar de facto para proyectos React en producción.
Las piezas clave del framework
Routing basado en el filesystem
En la mayoría de los frameworks, definir rutas implica configurar un archivo o una librería aparte donde se mapea cada URL a un componente. Con el tiempo, ese archivo crece, se vuelve difícil de mantener y es una fuente frecuente de conflictos en equipos grandes.
Next.js resuelve esto con una de sus decisiones más elegantes: la estructura de carpetas define las rutas. No hay archivo de configuración. Crear una carpeta blog/ con un archivo page.tsx adentro genera automáticamente la ruta /blog. Una carpeta [slug]/ genera una ruta dinámica que acepta cualquier valor en la URL (por ejemplo, /blog/mi-primer-post). Una carpeta (marketing)/ agrupa rutas sin afectar la URL, útil para organizar el código internamente sin que eso cambie lo que ve el usuario.
Además, cada ruta puede tener sus propios archivos especiales: layout.tsx para definir UI compartida entre varias páginas, loading.tsx para mostrar un skeleton mientras se cargan los datos, error.tsx para capturar errores sin que se caiga toda la aplicación y not-found.tsx para personalizar el 404.
Server Components y Client Components
Este es uno de los cambios más importantes que introdujo Next.js y también uno de los más frecuentemente mal entendidos.
Tradicionalmente, los componentes de React se ejecutan en el navegador: el servidor envía el código y el browser hace todo el trabajo. El problema es que eso implica enviar mucho JavaScript al cliente, incluyendo lógica que no necesita interactividad (un listado de productos, un artículo de blog, una tabla de datos).
Next.js invierte ese modelo. Por defecto, todos los componentes son Server Components: se renderizan en el servidor, el resultado se envía como HTML listo y no agregan ni una línea de JavaScript al bundle del cliente. Solo cuando un componente necesita interactividad real (manejar clicks, mantener estado, usar hooks como useState o useEffect) se agrega la directiva “use client” al inicio del archivo para convertirlo en un Client Component.
Esto permite construir aplicaciones más livianas y rápidas, enviando al browser únicamente el JavaScript que realmente necesita ejecutar.
Cuatro modos de renderizado
A diferencia de la mayoría de los frameworks que obligan a elegir una estrategia de rendering para toda la aplicación, Next.js soporta los cuatro modos, incluso en la misma página:
- CSR (Client-Side Rendering): el browser construye la UI con JavaScript. Ideal para secciones privadas como dashboards donde el SEO no importa.
- SSR (Server-Side Rendering): el servidor genera el HTML en cada request. Ideal para páginas que necesitan datos actualizados y buen posicionamiento, como resultados de búsqueda o contenido personalizado.
- SSG (Static Site Generation): el HTML se genera una sola vez durante el build. Ideal para contenido que no cambia seguido, como blogs, documentación o landings.
- ISR (Incremental Static Regeneration): combina lo mejor de SSG y SSR. La página se sirve estática, pero se regenera en segundo plano cada N segundos. Perfecto para catálogos de e-commerce o feeds de noticias.
La clave es que cada página o componente puede usar el modo que mejor se adapte a su caso, y esa decisión se puede cambiar sin refactorizar la arquitectura.
Data fetching integrado
En React puro, obtener datos desde un servidor implica manejar estados de carga, efectos secundarios y librerías adicionales como React Query. Es código repetitivo que todo equipo termina escribiendo de alguna forma.
En Next.js con Server Components, el modelo cambia por completo: un componente puede ser directamente async y hacer consultas de los datos en el servidor. Los datos llegan al cliente ya resueltos, sin estado de carga visible, sin efectos secundarios y sin agregar JavaScript extra al bundle.
Además, Next.js permite controlar la estrategia de caché a nivel de cada request: se puede forzar datos recientes en cada visita, cachear indefinidamente, o revalidar después de un tiempo determinado. Esa granularidad evita tener que elegir entre “todo estático” o “todo dinámico” a nivel de aplicación.
Backend dentro del mismo proyecto
Uno de los cambios más significativos del ecosistema web reciente es la difuminación de la línea entre frontend y backend. Next.js abraza esa tendencia con dos mecanismos:
API Routes permiten crear endpoints REST clásicos dentro del mismo proyecto, sin necesidad de un servidor aparte. Útil para webhooks, integraciones con servicios externos o cualquier endpoint consumido por clientes fuera de la aplicación.
Server Actions van un paso más allá: son funciones que corren en el servidor, pero se invocan directamente desde la UI. Cuando un usuario envía un formulario, la función se ejecuta en el servidor, valida los datos, escribe en la base de datos y puede revalidar la página, todo en un solo flujo. Esto elimina una capa entera de boilerplate que históricamente requería armar una API solo para que el frontend pudiera hablar con el backend.
¿Cómo se compara con Angular?
Esta comparación surgió durante la charla porque es una pregunta recurrente en equipos que evalúan frameworks. La respuesta no es “uno gana y el otro pierde” — responden a filosofías distintas.
Angular es opinado: toma decisiones por el equipo (routing, HTTP, formularios, inyección de dependencias) y escala bien en proyectos grandes con muchos desarrolladores. La consistencia es su mayor valor: si conocés un proyecto Angular, conocés todos. A cambio, la curva de aprendizaje es más pronunciada y los cambios de paradigma entre versiones (como la transición a standalone components o de RxJS a signals) tienen un costo real de migración.
Next.js es flexible: delega muchas decisiones al equipo, lo que da libertad pero también puede generar inconsistencias si no hay criterios claros. Su mayor ventaja es la velocidad para ir de idea a producción y la capacidad de elegir exactamente las herramientas que necesita cada proyecto.
En la práctica, la elección depende del contexto del equipo: su experiencia previa, el tipo de proyecto, el tamaño del equipo y las herramientas con las que ya trabaja.
El factor IA en la elección de stack
Un aspecto que pocos equipos consideran al evaluar frameworks es cómo interactúan con las herramientas de IA. Los modelos están entrenados desproporcionadamente con código React + Next.js + Tailwind, simplemente porque hay mucho más código público en ese stack que en cualquier otro. Herramientas como v0, Cursor y Claude Code generan ese stack de forma natural y con mejor calidad que otros frameworks.
Eso tiene consecuencias concretas. Los prototipos se arman más rápido porque la IA genera componentes funcionales con menos iteraciones. Los refactors son más confiables porque el modelo entiende mejor las convenciones de Next.js. Y el onboarding de nuevos desarrolladores se acelera porque pueden apoyarse en la IA para entender la estructura del proyecto.
No invalida elegir otro stack, pero es un factor de productividad que debería entrar en el cálculo. La calidad del output de la IA no es uniforme entre frameworks, y eso tiene un impacto económico que se acumula sprint a sprint.
Conclusión
Next.js resuelve problemas que React deja abiertos: routing, rendering, data fetching, optimización. No los resuelve con parches o librerías sueltas, sino con un framework que integra todo y permite elegir al equipo de desarrollo cómo renderizar cada parte de la aplicación según lo que necesite.
¿Es para todos? No. Pero para equipos que trabajan con React y necesitan SEO, performance y velocidad de desarrollo, es difícil encontrar una alternativa más completa. Y el hecho de que las herramientas de IA generen mejor código en este stack es un dato que, se quiera o no, termina pesando en el día a día.
Braian de Barros forma parte del equipo de desarrollo de Urudata Software. En las Tech Talks 2026 compartió la charla “Next.js”, donde abordó herramientas, enfoques y experiencias vinculadas al desarrollo web moderno.
