Next.js o React simple con Vite: cómo elegir el framework adecuado para tu proyecto.

En muchos equipos que usan React, Next.js es la solución antes incluso de que alguien haga la pregunta. La documentación es excelente, el ecosistema es enorme, el despliegue es sencillo, y existe la creencia general de que hace que las páginas sean más rápidas y se clasifiquen mejor, por lo que comenzar cada proyecto con él parece ser la opción segura. Sin embargo, un framework sigue siendo una herramienta con una función específica, y Next.js puede generar tanto estrés en un proyecto inadecuado como ahorro en uno adecuado. A continuación se presenta una forma práctica de decidir: qué problemas resuelve realmente Next.js (SSR, SEO, renderizado mixto), dónde realmente da sus frutos, los casos comunes en los que React puro con Vite es más adecuado, y cómo presentar esta elección a tu equipo como un requisito en lugar de una preferencia.

Qué agrega realmente Next.js a React

Si dejamos de lado el marketing, Next.js se centra principalmente en cómo y dónde se renderiza tu código React. Concretamente, ofrece:

• Renderizado en servidor (SSR), generación estática en tiempo de compilación (SSG) y combinaciones de ambos, aplicados sobre React.
• Enrutamiento basado en archivos, de modo que la estructura de carpetas define las URLs en lugar de una tabla de rutas escrita a mano.
• Una capa de backend ligera que viene incluida con el frontend: controladores de rutas API, middleware y funciones de edge, lo que permite que una única base de código sirva una aplicación full-stack.
• Integración estrecha con plataformas de hosting modernas, sobre todo Vercel, para el caché, la distribución desde el edge y el despliegue.

Esa lista se resume en una frase que vale la pena tener en mente para el resto de la discusión: Next.js se destaca cuando el rendimiento en la carga inicial, el SEO y la unificación de los aspectos frontend y backend bajo un mismo framework son realmente importantes para el proyecto. Cada escenario que se menciona a continuación es, en realidad, una prueba de esa afirmación.

Proyectos donde Next.js realmente rinde frutos

La visibilidad en búsquedas y la carga inicial son requisitos comerciales

Algunos productos dependen por completo del tráfico orgánico y de las primeras impresiones:

• sitios de marketing y páginas de destino de productos
• blogs con mucho contenido y portales de documentación
• tiendas en línea que dependen de las búsquedas

En estos casos, el renderizado en servidor y la generación estática no son lujos. El navegador recibe HTML completo antes de que se ejecute cualquier JavaScript, por lo que los usuarios ven el contenido más rápido y los rastreadores pueden indexar el texto real en lugar de un elemento raíz vacío. Next.js también permite prerenderizar páginas con sus datos, gestionar metatags de manera ordenada por ruta y utilizar la Regeneración Estática Incremental (ISR) para actualizar el contenido sin tener que reconstruir toda la página cada vez que algo cambia. Es posible reunir las mismas funcionalidades en una aplicación de página única básica, pero rara vez de forma tan eficiente.

Quieres un framework para toda la pila

Considera proyectos como estos:

• un producto SaaS pequeño o mediano
• un panel de control respaldado por unos pocos puntos de extremo autenticados
• una aplicación web típica donde el mismo equipo se encarga del frontend y del backend

Next.js permite que el código de API y los componentes de React coexistan en el mismo proyecto. Puedes escribir controladores de puntos de extremo en app/api (o pages/api si utilizas el enrutador Pages más antiguo), usar middleware para comprobaciones de autenticación, localización y redirecciones, y desplegar todo en cualquier plataforma que soporte Next.js, lo que incluye a Vercel pero no se limita a él.

Para un desarrollador individual o un equipo pequeño, esa consolidación es valiosa. No hay un servidor Node o Express separado que configurar ni un segundo pipeline de despliegue que mantener. La lógica del servidor se encuentra junto a los componentes que la utilizan, y el framework coordina el enrutamiento y la renderización entre ellos.

Las áreas públicas y privadas requieren una renderización diferente

Muchas aplicaciones se dividen naturalmente en dos partes: páginas públicas mayormente estáticas como la página de inicio, la información de precios y la documentación, y áreas dinámicas para usuarios conectados como un panel de control o una consola de administración. Next.js maneja bien esta combinación. Puedes generar de forma estática contenido que rara vez cambia, renderizar páginas por usuario en el servidor y mantener widgets altamente interactivos exclusivamente en el cliente, donde el renderizado en servidor aporta poco. La verdadera ventaja es poder elegir la estrategia de renderizado para cada ruta, de modo que puedas ajustar el rendimiento de cada parte del producto sin tener que cambiar de framework ni mantener dos bases de código.

Proyectos en los que React puro suele ser la mejor opción

Estos casos son comunes, y son precisamente donde los equipos tienden a recurrir a Next.js por costumbre.

Aplicaciones del lado del cliente que nadie encuentra mediante búsquedas

Imagínese las operaciones internas o los paneles de análisis, los paneles de administración tras un proceso de inicio de sesión, y las herramientas a través de las cuales cada usuario accede directamente a la aplicación en lugar de a través de un motor de búsqueda. En estos productos, todos los datos se obtienen después de que se carga la aplicación; un documento HTML inicial vacío es irrelevante porque los rastreadores no constituyen su público objetivo, y los problemas de rendimiento que realmente importan son de tipo cliente: la gestión del estado, la obtención de datos y la eficiencia en la renderización.

Next.js incluye capacidades del servidor que no utilizarás, un entorno de ejecución del servidor que no necesitas, además de conceptos adicionales relacionados con el enrutamiento y la carga de datos. Una aplicación React creada con Vite, Parcel o incluso con una configuración básica de webpack suele ser más rápida de desarrollar y más fácil de comprender para todos. Si deseas repasar qué implica dicha configuración, consulta nuestra guía paso a paso para crear tu primera aplicación React con Vite.

Una regla práctica: cuando cada pantalla importante está protegida por autenticación y los usuarios acceden a ella a través de una URL conocida o de una interfaz de aplicación, Next.js es opcional y no necesario.

Widgets, bibliotecas de componentes y herramientas integrables

A veces el resultado final no es en absoluto un sitio web. Puede tratarse de un widget incrustable publicado en npm, de un sistema de diseño compartido o de una herramienta de una sola pantalla que se integrará dentro de la aplicación de otra persona. Lo que se entrega es una interfaz de usuario reutilizable, no páginas, por lo que el enrutamiento, el SSR, el SSG y una estructura de carpetas predeterminada resuelven problemas que en realidad no existen.

Una compilación ligera con React es la mejor opción aquí por tres razones. Se puede compilar y publicar sin tener que adaptarse a las convenciones del framework. Los usuarios de tu paquete deciden cómo y dónde se renderiza. Además, se evitan suposiciones específicas de Next.js en un código que debería funcionar en cualquier lugar. Si tu proyecto no cuenta con páginas reales, un framework organizado en torno a páginas es el punto de partida incorrecto.

Enrutamiento que no se relaciona con carpetas

El enrutamiento basado en archivos es conveniente para muchas aplicaciones, pero sigue siendo una limitación. La estructura de las URL está vinculada a la estructura de los directorios, ciertos patrones avanzados requieren soluciones alternativas, y el enrutamiento altamente orientado a los datos puede parecer forzado. Si su aplicación tiene rutas profundamente anidadas y altamente dinámicas, un modelo de navegación que no se asemeja a un árbol de archivos, o esquemas de URL inusuales dictados por reglas de negocio, React combinado con un enrutador programático como React Router podría ser más adecuado para usted. Definir las rutas en código le brinda un control total en lugar de tener que adaptar su diseño al layout esperado del framework.

La pregunta que debe hacerse es si el enrutamiento basado en archivos simplifica su modelo mental o si, por el contrario, le dificulta su trabajo. Si le dificulta las cosas, es probable que React puro sea la mejor opción.

Contenido mayormente estático con poca interactividad

Next.js puede generar sitios estáticos, pero el resultado sigue incluyendo el entorno de ejecución de React y los costos asociados a la hidratación. En el caso de páginas simples de marketing, documentación con poca interactividad, portafolios y sitios con contenido limitado, eso puede significar que se envíe mucho más JavaScript del necesario para esas páginas. Herramientas para sitios estáticos como Astro, Eleventy o Hugo, o incluso HTML y CSS escritos a mano con un poco de JavaScript cuando es necesario, suelen producir cargas más pequeñas y despliegues más sencillos.

En resumen, si una página se comporta como un documento en lugar de como una aplicación, un meta-marco de React representa más complejidad de la que realmente se necesita.

Hosting que no puede ejecutar código de servidor

Next.js funciona de la mejor manera cuando se puede desplegar en una plataforma que ejecuta funciones Node o serverless y se utilizan realmente SSR, funciones de borde o rutas API. Tu situación podría ser diferente: hosting exclusivamente estático como GitHub Pages, Netlify en modo puramente estático o S3 detrás de CloudFront; una política que prohíbe procesos Node de larga duración; o un presupuesto en el que pagar por cada invocación serverless no es viable.

En ese caso, una compilación estática de React con una herramienta como Vite es más sencilla: se generan los recursos, se suben y listo. Next.js sí ofrece un modo de exportación estática para esta situación, pero se pierden funcionalidades dependientes del servidor como ISR, middleware y controladores de rutas que necesitan un servidor en el momento de la solicitud, por lo que hay que consultar la documentación actual para saber qué se admite exactamente. Si te encuentras usando Next.js sin tocar nunca SSR, rutas API o middleware, en realidad lo estás utilizando principalmente como un bundler avanzado.

La experiencia del equipo forma parte de la decisión

La idoneidad técnica es solo la mitad de la ecuación; también es importante el conocimiento que tenga su equipo. Supongamos que el equipo está familiarizado con React del lado del cliente y los patrones de página única, pero tiene poca experiencia con SSR, transmisión en tiempo real o obtención de datos en Components de servidor, y necesita implementar funcionalidades del producto en lugar de invertir en ingeniería de plataforma. Adoptar Next.js implica entonces asumir:

• nuevos modelos mentales, incluidos los Components de servidor, la carga de datos del lado del servidor y las convenciones de enrutamiento
• complejidad operativa relacionada con los destinos de despliegue, las capas de caché y el comportamiento en los nodos periféricos
• más elementos que inspeccionar cuando ocurren problemas al renderizar o al hidratar

Esa inversión definitivamente puede valer la pena, pero representa un costo real. Para un producto pequeño o una herramienta interna, seguir utilizando una tecnología que el equipo conoce a fondo suele ser la mejor opción en lugar de adoptar algo solo porque parece más moderno. Si está considerando las características más recientes del framework, nuestro mapa de las características modernas de Next.js y qué reemplazan cada una es una buena forma de evaluar cuánto nuevo hay que aprender.

Lista de verificación para tomar decisiones en proyectos nuevos

Responda a estas preguntas al inicio de cualquier proyecto basado en React:

1. ¿Necesita SSR o SSG para el SEO o para mejorar el rendimiento al cargar la página por primera vez? Si es así, Next.js es una excelente opción; de lo contrario, React puro es perfectamente suficiente.
2. ¿Se trata de un sitio compuesto por páginas reales o principalmente por una estructura de aplicación? Muchas páginas de contenido apuntan a Next.js; una interfaz de una sola capa sugiere una aplicación de página única con React.
3. ¿Desea tener un backend pequeño junto al frontend? Si le resultan atractivas las rutas API y el middleware en el mismo repositorio, Next.js es la opción adecuada. Si ya existe un backend dedicado, ya sea en NestJS, Spring Boot, Laravel u otro sistema, Next.js aporta menos valor.
4. ¿Dónde se alojará y con qué presupuesto? La capacidad y disposición para pagar por los procesos del servidor o las invocaciones de funciones mantienen a Next.js como opción viable. Si solo está disponible el alojamiento estático, una versión ligera de React suele ser la mejor opción.
5. ¿Qué sabe bien el equipo actualmente? Si todos son expertos en React pero solo unas pocas personas entienden SSR y los componentes del servidor, pregunte si los requisitos del proyecto justifican realmente esa curva de aprendizaje.

Nada de esto obliga a adoptar una postura de todo o nada. No es necesario estandarizar todo en Next.js ni descartarlo por completo. La actitud adecuada es considerarlo como una opción más en su caja de herramientas de React, elegida deliberadamente cuando sus ventajas se alineen con sus necesidades.

Enmarcando la elección para su equipo

Si usted es quien toma o influye en esta decisión, evite presentarla como “Next.js es un exceso”, ya que suena a una cuestión de gusto. En su lugar, base la decisión en trade-offs que el equipo pueda evaluar:

• “Este panel interno obtiene pocos beneficios de SSR o SEO, por lo que Next.js añadiría carga adicional sin un beneficio claro.”
• “La biblioteca de componentes no tiene páginas ni rutas, por lo que una configuración básica de React es más adecuada para ella.”
• “Nuestro servicio de hosting solo sirve archivos estáticos, por lo que la mayoría de las funcionalidades de Next.js quedarían sin uso.”
• “Utilizaremos Next.js en productos públicos con mucho contenido donde la rendimiento y la indexación son cruciales, y mantendremos React puro para las herramientas internas.”

Declaraciones como estas mantienen la conversación centrada en los requisitos en lugar de en las tendencias, y facilitan volver a evaluar la decisión si esos requisitos cambian.

Dejen que los requisitos elijan el framework

La elección entre Next.js y React puro no se trata de cuál es más moderno; se trata de qué tipo de problemas tiene realmente su proyecto. El renderizado en servidor, el SEO, las estrategias de renderizado por ruta y un backend colocado son verdaderas ventajas cuando se necesitan, pero representan una carga adicional cuando no es necesario. Partan de los requisitos de la lista anterior, tengan en cuenta las limitaciones de su hosting y la experiencia de su equipo, y dejen que el framework surja de esas respuestas y no al revés.

Leer más

• ¿Acciones de servidor o manejadores de ruta? Una guía de toma de decisiones para Next.js 16: Aprenda cuándo una mutación en Next.js 16 debe incluirse en una acción de servidor y cuándo necesita un manejador de ruta, con ejemplos corregidos para formularios, errores, enfoque optimista y webhooks.
• Separar las capas de dominio, datos y UI en un códigobase de Next.js App Router: Un estudio de caso de Pokédex que muestra cómo dividir una aplicación de Next.js App Router en capas de dominio, datos y presentación utilizando Prisma, Zod, autenticación por cookies y caché.

Estado de URL, estado del servidor y un BFF: Un stack Vite para aplicaciones React internas: Por qué una plataforma React interna autenticada puede beneficiarse más de Vite, TanStack Router, TanStack Query y un BFF separado que de Next.js, y cuándo deja de ser cierto.