nextjs.org

Next.js es un framework de React para crear aplicaciones web full-stack. React proporciona el modelo de componentes para las interfaces de usuario; Next.js añade enrutamiento, renderizado, convenciones de acceso a datos, capacidades de servidor, compilación, empaquetado, almacenamiento en caché y herramientas orientadas a producción.

El tema principal es el framework, no su dominio. nextjs.org es el sitio web oficial donde los visitantes pueden encontrar documentación mantenida, guías, enlaces de la comunidad e información sobre el proyecto.

Next.js es especialmente relevante cuando un equipo quiere desarrollar con React y ofrecer algo más que una interfaz exclusiva para el navegador. Un proyecto puede contener páginas prerenderizadas, respuestas generadas al recibir solicitudes, acceso a datos del lado del servidor, endpoints similares a los de una API y componentes interactivos que se ejecutan en el navegador.

Qué añade Next.js a React

React ayuda a los desarrolladores a describir interfaces como componentes, pero no prescribe una arquitectura completa para las aplicaciones. Next.js aporta convenciones para asignar archivos a rutas, decidir dónde se ejecuta el código, cargar datos, generar respuestas y preparar una aplicación para su despliegue.

Por tanto, su valor va más allá del renderizado del lado del servidor. Una aplicación Next.js puede emplear varios métodos de renderizado y entrega, a veces dentro del mismo proyecto. El framework coordina esos métodos en torno a React en lugar de imponer un único modelo a todas las rutas.

Un resumen útil de esta división es:

• React define los componentes, el estado, las props y la composición de la interfaz.
• Next.js define las rutas, los layouts, las opciones de renderizado, los puntos de entrada del servidor y el comportamiento de compilación.
• La aplicación define sus reglas de datos, límites de cliente, política de caché y requisitos de despliegue.
• El entorno de alojamiento determina qué funciones de ejecución están disponibles y cómo operan.

Esta separación es importante al comparar Next.js con una aplicación cliente de React, un generador de sitios estáticos u otro framework web. El framework ofrece una amplia variedad de capacidades, pero un proyecto solo se beneficia de las que utiliza correctamente.

Componentes de servidor y de cliente

En el App Router, los layouts y las páginas son Server Components de forma predeterminada. Los Server Components se ejecutan en un entorno de servidor y pueden realizar tareas de datos del lado del servidor sin enviar al navegador la implementación de sus componentes.

Los Client Components se utilizan cuando una parte de la interfaz necesita estado del navegador, controladores de eventos, efectos o API exclusivas del navegador. Los desarrolladores marcan un límite de cliente con la directiva use client, y los componentes situados bajo ese límite pasan a formar parte del grafo de módulos del lado del cliente.

Pregunta	Server Component	Client Component
¿Dónde se ejecuta la lógica de su componente?	En el entorno de renderizado del servidor	En el navegador después de incluirse en el paquete del cliente
¿Puede usar el estado del navegador o controladores de clics?	No	Sí
¿Puede usar directamente API exclusivas del navegador?	No	Sí
¿Se envía al navegador el código de su componente?	No como código de componente del cliente	Sí
Función habitual	Contenido respaldado por datos, layouts y composición del lado del servidor	Formularios, menús, editores, filtros y otros controles interactivos

Una ruta no tiene que elegir exclusivamente un tipo. Un Server Component puede renderizar contenido y componer Client Components seleccionados para las partes interactivas de la página. Esto permite a los equipos situar JavaScript del navegador en torno a necesidades concretas en lugar de tratar toda la ruta como una aplicación cliente.

El límite sigue requiriendo cuidado. Colocar un gran subárbol de componentes detrás de use client puede enviar más JavaScript al navegador, mientras que dividir cada pequeño control en un límite independiente puede dificultar la comprensión del código. Las páginas representativas deben medirse en lugar de evaluarse únicamente por la etiqueta del framework.

Los Server Components también son distintos de la estrategia de entrega de una ruta. Un Server Component puede contribuir a una salida prerenderizada o participar en el renderizado dinámico. Describir un componente como del lado del servidor no indica por sí solo si la ruta se genera durante una compilación, se actualiza posteriormente o se produce con cada solicitud.

App Router y Pages Router

Next.js documenta actualmente dos sistemas de enrutamiento. El App Router es el sistema más reciente e incorpora funciones de React como los Server Components. El Pages Router es el sistema anterior y continúa siendo compatible.

Área	App Router	Pages Router
Estructura principal de las rutas	El directorio app	El directorio pages
Modelo de componentes predeterminado	Los layouts y las páginas son Server Components	Utiliza el modelo anterior de páginas de Next.js
Interfaz compartida	Los layouts anidados son una convención central	Suele componerse mediante patrones de aplicación y de página
Mejor punto de partida	Proyectos nuevos que adopten la arquitectura actual	Aplicaciones existentes o dependencias creadas en torno a las API de Pages Router

Una migración implica más que cambiar el nombre de las carpetas. El código de App Router introduce un modelo de componentes centrado primero en el servidor y patrones diferentes para los layouts, el acceso a datos, los estados de carga y el comportamiento de las rutas. Los equipos deben identificar esos cambios conceptuales antes de convertir una aplicación consolidada.

Los proyectos nuevos normalmente deberían estudiar primero la documentación de App Router porque explica el modelo actual del framework. Las aplicaciones existentes con Pages Router deberían evaluar la migración según los beneficios reales, las dependencias, el esfuerzo de prueba y el coste de mantenimiento, en lugar de considerar que la continuidad de su compatibilidad es un defecto.

La documentación y los ejemplos pueden estar destinados a un solo enrutador. Antes de copiar una implementación, los desarrolladores deben confirmar qué enrutador utiliza y si las API citadas se aplican a su proyecto.

Renderizado, almacenamiento en caché y revalidación

Next.js no renderiza todas las páginas de la misma manera. Una ruta puede prepararse antes de que llegue un visitante, generarse mediante información específica de la solicitud, almacenarse en caché o actualizarse conforme a una política de revalidación.

Necesidad de la ruta	Enfoque de entrega probable	Pregunta que debe verificarse
Las entradas se conocen de antemano	Salida prerenderizada	¿Qué evento debería provocar que cambie la salida?
La salida depende de cookies, encabezados o datos de la solicitud	Renderizado dinámico	¿Puede seguir almacenándose en caché de forma segura alguna parte del trabajo?
El contenido cambia según un calendario controlado	Salida almacenada en caché con revalidación	¿Hasta qué punto puede quedar desactualizada la respuesta?
No se necesita ninguna función exclusiva del servidor	La exportación estática puede ser adecuada	¿Son compatibles todas las rutas y recursos con las limitaciones de la exportación?

El almacenamiento en caché no es un único interruptor que pueda entenderse de forma independiente del acceso a datos. Los equipos deben saber qué operaciones se almacenan en caché, qué rutas pasan a ser dinámicas y cómo se produce la invalidación o revalidación. Esas reglas deben probarse con cambios de contenido realistas.

Esto es especialmente importante para páginas autenticadas, precios, inventarios, paneles y otra información con requisitos explícitos de vigencia. Ofrecer una salida almacenada en caché puede ser valioso, pero solo cuando las reglas de corrección de la aplicación lo permiten.

El rendimiento y la visibilidad en buscadores no deben deducirse únicamente de la etiqueta de renderizado. El prerenderizado puede reducir el trabajo al recibir una solicitud y el renderizado en el servidor puede proporcionar HTML inicial significativo, pero los resultados reales dependen de la estructura de la página, los recursos, la latencia de los datos, el JavaScript del navegador, la caché y el comportamiento del despliegue.

Exportación estática y requisitos de ejecución

Next.js puede generar una exportación estática cuando el proyecto no depende de funciones del framework exclusivas del servidor. El HTML, CSS, JavaScript y los recursos resultantes pueden servirse mediante una infraestructura compatible con archivos estáticos convencionales.

La salida estática puede seguir incluyendo Client Components. La entrega estática describe cómo se aloja el resultado compilado; no significa que todas las interfaces deban carecer de interactividad. El código del lado del navegador puede seguir proporcionando estado, eventos y otros comportamientos del cliente.

Antes de elegir la exportación estática, comprueba que el proyecto no requiera:

• Respuestas generadas a partir de datos del servidor específicos de la solicitud.
• Comportamiento de rutas que dependa de un entorno de ejecución activo de Next.js.
• Funciones de imágenes, enrutamiento o servidor no compatibles.
• Reglas de vigencia que no puedan cumplirse mediante una nueva compilación u otro proceso de actualización compatible.
• Endpoints de servidor que deban ejecutarse junto a la aplicación.

Cuando se necesitan esas capacidades, la aplicación requiere un entorno de ejecución compatible. Esto no exige desplegar en Vercel: la guía oficial de despliegue documenta el alojamiento propio y los adaptadores de plataformas. La compatibilidad difiere según la plataforma, por lo que debe comprobarse respecto a las funciones concretas que se utilicen.

Route Handlers y endpoints del lado del servidor

En el App Router, los Route Handlers permiten que una aplicación defina controladores de solicitudes HTTP mediante conceptos estándar de solicitud y respuesta. Son útiles para endpoints que pertenecen junto a la aplicación, incluido el procesamiento de formularios, webhooks, respuestas de datos o callbacks de integraciones.

Un Route Handler no es automáticamente el lugar adecuado para todos los sistemas de backend. Los equipos aún deben decidir cómo se gestionan la autenticación, autorización, validación, los controles de frecuencia, el trabajo duradero y el manejo de errores. Puede ser preferible separar de la aplicación web los servicios de larga duración o que escalan de forma independiente.

Una revisión práctica plantea:

1. ¿Necesita el endpoint acceso al código de la aplicación o a tipos compartidos?
2. ¿Requiere secretos disponibles al recibir la solicitud o dependencias exclusivas del servidor?
3. ¿Puede el destino de despliegue ejecutar el controlador tal como está documentado?
4. ¿Qué comportamiento de caché es correcto para cada método HTTP y respuesta?
5. ¿Ofrecería un servicio independiente una propiedad o un escalado más claros?

Los Route Handlers facilitan la composición full-stack, pero esa comodidad no elimina las responsabilidades habituales de diseño y seguridad de las API.

Cuándo Next.js es una opción práctica

Next.js es un candidato sólido para equipos que ya se sienten cómodos con React y necesitan enrutamiento de aplicaciones y capacidades de servidor en el mismo código base. También puede ser adecuado para productos cuyas rutas tienen necesidades de entrega considerablemente diferentes.

Los casos habituales incluyen:

• Áreas de cuenta y paneles con datos del servidor y controles interactivos.
• Experiencias comerciales o de catálogo que combinan contenido estable con información dependiente de la solicitud.
• Sitios de documentación o marketing que también incluyen flujos de trabajo de la aplicación.
• Productos que necesitan respuestas HTML, interacción del cliente y endpoints de servidor conjuntamente.
• Aplicaciones React cuyas rutas se benefician de políticas de caché y renderizado independientes.

El framework puede implicar más complejidad de la necesaria para un sitio de contenido sencillo. Un equipo que publique principalmente artículos estáticos debería comparar sus necesidades con herramientas centradas en la entrega de contenido, especialmente si solo una pequeña parte del sitio necesita interacción con React.

Next.js también puede ser una mala opción cuando el equipo no puede admitir sus requisitos de ejecución, no desea conceptos de renderizado específicos del framework o tendría dificultades para mantener límites claros entre servidor y cliente. La flexibilidad solo resulta valiosa cuando la arquitectura sigue siendo comprensible.

Comparación de Next.js con Astro y otras opciones

Next.js y Astro suelen evaluarse para proyectos que combinan contenido con elementos interactivos, pero sus valores predeterminados y modelos mentales son diferentes. La opción apropiada depende de las rutas reales, no de una afirmación general de que un framework es más rápido o mejor.

Para realizar una comparación útil, crea la misma página representativa en cada candidato y registra:

• Cuánto JavaScript llega al navegador antes y después de la interacción.
• Cómo se cargan los datos y cómo se controla su vigencia.
• Si se necesitan funciones de ejecución del servidor.
• Cómo se implementan el enrutamiento, los layouts, los formularios y los estados de error.
• Si el alojamiento de destino admite todas las funciones necesarias.
• Con qué facilidad puede el equipo probar y explicar la arquitectura resultante.

Astro merece especial consideración para sitios centrados en contenido donde la mayor parte de la salida pueda permanecer estática y las islas interactivas sean limitadas. Next.js resulta más convincente cuando React es el modelo central de la aplicación y es necesario componer funciones de servidor y cliente en todo el producto.

Ninguna de las comparaciones predice una puntuación de rendimiento. Las imágenes, fuentes, scripts de terceros, decisiones sobre componentes, latencia de los datos y límites del cliente pueden pesar más que los valores predeterminados del framework.

Orígenes, gobernanza y comunidad

La página oficial de gobernanza afirma que el equipo de Vercel creó Next.js en 2016. También indica que el equipo central de Vercel dirige la investigación y el desarrollo del proyecto. Esta es una declaración sobre el origen y la gobernanza a nivel de equipo; no debe sustituirse por una afirmación sin respaldo sobre un fundador individual.

Según lo documentado en las páginas de gobernanza y documentación disponibles el 27 de agosto de 2026, las vías de participación pública del proyecto incluyen:

• El repositorio oficial de GitHub para el código fuente, los problemas y la actividad del proyecto.
• GitHub Discussions para preguntas y debates comunitarios sobre RFC.
• El Discord de Next.js para recibir asistencia gratuita de la comunidad.
• Documentación mantenida tanto para App Router como para Pages Router.

Estos canales ofrecen diferentes tipos de ayuda. La documentación debe ser la primera referencia para conocer el comportamiento del framework, Discussions puede revelar propuestas y preguntas compartidas, y Discord puede facilitar la conversación de la comunidad. Ninguno sustituye las pruebas específicas del proyecto ni el proceso propio de asistencia en producción de un equipo.

Lista de comprobación para tomar una decisión

Antes de adoptar Next.js, los equipos deberían responder estas preguntas mediante un prototipo funcional:

• ¿Qué rutas son estáticas, dinámicas, se almacenan en caché o se revalidan?
• ¿Qué componentes requieren realmente estado, efectos, eventos o API del navegador?
• ¿Cuánto JavaScript del cliente envía cada ruta representativa?
• ¿Qué endpoints pertenecen a Route Handlers y cuáles deberían estar en otro lugar?
• ¿Puede la plataforma de destino ejecutar todas las funciones necesarias de Next.js?
• ¿Cómo se gestionarán la vigencia de la caché, los fallos, los registros y los despliegues?
• ¿Comprende el equipo las diferencias entre el enrutador elegido y los ejemplos escritos para el otro enrutador?

Next.js consiste en aplicar React a una aplicación web completa mientras se elige deliberadamente dónde se realiza el trabajo y cómo se entrega cada ruta. Su flexibilidad documentada es considerable, pero no garantiza rendimiento, resultados de búsqueda, costes operativos bajos ni simplicidad arquitectónica. Esos resultados deben determinarse mediante la implementación y la medición.