Crea sitios web y aplicaciones Vue con enrutamiento, lógica de servidor y renderizado flexible
Nuxt es un framework gratuito y de código abierto para crear sitios web y aplicaciones full-stack con Vue. Proporciona enrutamiento, renderizado, funciones de servidor, convenciones para el manejo de datos, herramientas de desarrollo y compatibilidad con despliegues, de modo que un equipo no tenga que ensamblar esos fundamentos por separado.
El tema principal aquí es Nuxt, el framework. nuxt.com es su sitio web oficial y centro de documentación, donde los desarrolladores pueden conocer el framework, los módulos, el equipo y los recursos de la comunidad.
¿De qué trata Nuxt?
Nuxt consiste en convertir componentes Vue en una aplicación estructurada que puede ejecutarse tanto en el servidor como en el navegador. Un proyecto Nuxt puede entregar HTML renderizado en el servidor, comportarse como una aplicación del lado del cliente, generar páginas estáticas o aplicar distintas reglas de renderizado y caché a diferentes rutas.
Su alcance va más allá de la generación de sitios estáticos. Nuxt puede servir para un sitio web de contenidos, una aplicación autenticada, endpoints de servidor o un producto que combine los tres.
Nuxt en un minuto
- Vue proporciona el modelo de interfaz. Los desarrolladores siguen escribiendo componentes Vue, plantillas, composables y estado reactivo.
- Nuxt proporciona la estructura de la aplicación. Los archivos y directorios reconocidos definen páginas, layouts, middleware, plugins, utilidades y manejadores de servidor.
- El renderizado universal es la opción predeterminada. El servidor puede producir la primera respuesta HTML antes de que Vue active el comportamiento interactivo en el navegador.
- El renderizado puede cambiar según la ruta. Las secciones estáticas, almacenadas en caché, renderizadas en el servidor y exclusivas del cliente pueden coexistir.
- Nitro impulsa la capa de servidor. Gestiona el renderizado en el servidor, los endpoints de API, el middleware y la salida orientada al despliegue.
- Nuxt Content es opcional. Los equipos pueden añadir un sistema de contenidos basado en archivos sin convertirlo en un requisito para todos los proyectos Nuxt.
¿Cómo se relaciona Nuxt con Vue?
Vue es el framework de interfaz de usuario en el que se basa Nuxt. Nuxt conserva el modelo de componentes de Vue y añade las decisiones complementarias necesarias para convertir los componentes en un sitio web o una aplicación con rutas y que se pueda desplegar.
Un desarrollador que trabaja con Nuxt sigue utilizando conceptos de Vue como componentes de archivo único, props, eventos, composables y reactividad. Nuxt añade convenciones sobre dónde se encuentran esos componentes, cómo llegan las URL a ellos, cuándo se obtienen los datos y si el código se ejecuta en el servidor, en el navegador o en ambos lugares.
| Aspecto | Función de Vue | Función de Nuxt |
|---|---|---|
| Interfaz | Componentes, plantillas y reactividad | Organiza los componentes en páginas y layouts |
| Navegación | Se integra con herramientas de enrutamiento | Crea rutas a partir de archivos en app/pages/ |
| HTML inicial | Proporciona primitivas de renderizado | Configura el renderizado en el servidor y el prerenderizado |
| Lógica de servidor | Fuera del alcance de la biblioteca principal de interfaz | Añade endpoints Nitro, middleware y utilidades de servidor |
| Despliegue | Lo elige la aplicación | Produce la salida mediante presets de despliegue de Nitro |
Esta estructura integrada reduce la configuración inicial y proporciona a los colaboradores un vocabulario de proyecto compartido. El coste es que los desarrolladores deben comprender comportamientos específicos de Nuxt, como las importaciones automáticas, el escaneo de directorios, la hidratación y los límites entre servidor y cliente.
¿Cómo se convierten los archivos en rutas y funciones de la aplicación?
Nuxt utiliza convenciones para conectar el sistema de archivos con el comportamiento de la aplicación. Un archivo Vue dentro de app/pages/ se convierte en una ruta, mientras que los nombres que contienen corchetes pueden representar parámetros dinámicos de URL.
El mismo enfoque se extiende más allá de las páginas. Los layouts envuelven vistas relacionadas, el middleware de rutas se ejecuta durante la navegación, los plugins configuran la aplicación Vue y los composables contienen lógica reutilizable con estado. Nuxt puede importar automáticamente componentes, composables y utilidades compatibles desde ubicaciones reconocidas.
Directorios habituales y sus funciones
| Directorio | Finalidad pública |
|---|---|
app/pages/ |
Crea rutas de aplicación a partir de archivos Vue |
app/layouts/ |
Define estructuras reutilizables para páginas |
app/components/ |
Almacena componentes reutilizables de interfaz Vue |
app/composables/ |
Contiene lógica reutilizable de composición de Vue |
app/middleware/ |
Ejecuta lógica durante la navegación entre rutas |
server/api/ |
Crea endpoints de servidor bajo /api |
server/routes/ |
Crea rutas de servidor sin el prefijo /api |
shared/ |
Contiene código destinado tanto a la aplicación Vue como al servidor Nitro |
El enrutamiento por archivos evita que los equipos tengan que mantener un registro de rutas separado para las páginas ordinarias. También significa que mover o cambiar el nombre de un archivo puede modificar una URL pública, por lo que la estructura de rutas merece la misma revisión que el código de la aplicación.
Las importaciones automáticas eliminan instrucciones repetitivas, pero su origen puede no estar claro para un nuevo colaborador. Los nombres explícitos, la compatibilidad del editor y una breve documentación del proyecto pueden facilitar la comprensión de esta comodidad.
¿Qué modos de renderizado admite Nuxt?
Nuxt admite renderizado universal, renderizado del lado del cliente, prerenderizado y renderizado híbrido. Estos modos describen cuándo se produce el HTML y cuánto trabajo queda para el servidor o el navegador.
El renderizado universal es el modelo documentado predeterminado. Nuxt renderiza el HTML inicial en el servidor, lo envía al visitante y después hidrata la página para que Vue pueda gestionar la interacción en el navegador.
| Modo | Qué sucede | Ejemplos adecuados | Implicación importante |
|---|---|---|---|
| Universal | Se produce HTML para la solicitud inicial y después se hidrata | Páginas públicas de productos o aplicaciones respaldadas por datos | El código del servidor y del navegador debe comportarse de forma coherente |
| Del lado del cliente | El navegador renderiza la estructura y la interfaz de la aplicación | Herramientas privadas dominadas por el estado del navegador | El HTML inicial puede contener menos contenido útil |
| Prerenderizado | El HTML se genera antes de las solicitudes | Documentación, guías y páginas de marketing estables | Las compilaciones deben descubrir o recibir todas las rutas previstas |
| Híbrido | Diferentes rutas reciben reglas distintas | Una publicación estática con un área de cuenta dinámica | Se debe probar y mantener más comportamiento específico de cada ruta |
El HTML renderizado en el servidor puede mejorar la rapidez con la que el contenido útil queda disponible, pero no garantiza páginas rápidas, buena visibilidad en buscadores ni paquetes de JavaScript pequeños. El peso de los componentes, el acceso a los datos, la caché, el alojamiento y la calidad de la implementación siguen determinando el resultado.
La salida estática tiene límites similares. El prerenderizado elimina el renderizado durante la solicitud para las páginas seleccionadas, pero las colecciones grandes de rutas pueden alargar las compilaciones, y los cambios de contenido pueden requerir regeneración salvo que se configure otra estrategia compatible.
¿Qué son las reglas de ruta y el renderizado híbrido?
Las reglas de ruta permiten que un proyecto Nuxt asigne comportamientos a patrones de URL coincidentes. Hacen posible el renderizado híbrido porque una sección puede prerenderizarse mientras otra permanece dinámica o se renderiza en el cliente.
Las reglas documentadas incluyen prerenderizado, redirecciones, desactivación del renderizado del lado del servidor para rutas seleccionadas, almacenamiento en caché, comportamiento stale-while-revalidate y regeneración incremental en plataformas compatibles. Algunas capacidades dependen del preset de despliegue y del entorno de alojamiento.
Un mapa de rutas práctico
- Una sección de documentación podría utilizar prerenderizado porque sus páginas cambian mediante una publicación editorial.
- Un catálogo de productos podría utilizar una regla de caché o stale-while-revalidate cuando sus datos cambian con mayor frecuencia.
- Un panel de cuenta podría utilizar renderizado del lado del cliente porque su contenido es privado y altamente interactivo.
- Una ruta de API podría recibir reglas de caché o de origen cruzado independientemente de las rutas de página.
- Una URL retirada podría recibir una redirección hacia su sustituta.
Las reglas de ruta son potentes cuando expresan un número reducido de categorías claras de contenido y aplicación. Una colección creciente de excepciones puede dificultar la predicción de la vigencia, la invalidación y el comportamiento en tiempo de ejecución.
La regeneración incremental merece una comprobación del despliegue. Nuxt documenta reglas de ruta orientadas a ISR, pero su comportamiento exacto depende de la integración con la plataforma seleccionada, en lugar de ser idéntico en todos los alojamientos.
¿Qué proporciona Nitro?
Nitro es el motor de servidor de Nuxt. Admite renderizado del lado del servidor, prerenderizado, manejadores de API, middleware, plugins de servidor y salidas destinadas a diferentes entornos de servidor o edge.
Los archivos de server/api/ se convierten en endpoints con el prefijo /api. Los archivos de server/routes/ crean rutas sin ese prefijo, mientras que el middleware de servidor puede inspeccionar o ampliar el contexto de la solicitud antes de que se ejecuten los manejadores.
Mantén visibles estos límites de ejecución
- El código exclusivo del servidor puede trabajar con credenciales privadas y servicios de confianza, pero los secretos nunca deben entrar en los paquetes del navegador.
- El código exclusivo del cliente puede utilizar las API del navegador, pero los visitantes pueden inspeccionar todo lo que se entrega a sus dispositivos.
- El código compartido debe ser seguro y compatible en todos los entornos de ejecución donde Nuxt lo ejecute.
- Los sistemas externos, como bases de datos, colas, proveedores de identidad y API independientes, conservan sus propios requisitos operativos y de seguridad.
Mantener el frontend y pequeños manejadores de servidor en un mismo proyecto puede simplificar el desarrollo. No significa que todo backend deba estar dentro de Nuxt, ni que Nitro elimine la necesidad de diseñar la autenticación, la validación, el almacenamiento, la observabilidad o la gestión de fallos.
Los presets de despliegue adaptan la salida de Nitro a los entornos compatibles. Los equipos deben probar el destino real porque los entornos de ejecución difieren en las API disponibles, la duración de los procesos, la integración de la caché y las restricciones operativas.
¿Es Nuxt adecuado para sitios web de contenidos?
Sí. Nuxt es útil para documentación, publicaciones, marketing y otros sitios web con mucho contenido, especialmente cuando esas páginas deben compartir componentes Vue con funciones interactivas del producto.
Un equipo puede obtener contenido de una API, de un sistema de gestión de contenidos independiente o de archivos locales. Nuxt Content es un módulo opcional para el enfoque basado en archivos locales.
Nuxt Content documenta compatibilidad con fuentes Markdown, YAML, CSV y JSON. Puede organizar el material en colecciones tipadas, consultar contenido, generar datos de navegación y utilizar MDC para insertar componentes Vue dentro de Markdown.
Dónde ayuda esta combinación
- Documentación de productos con ejemplos de código interactivos o calculadoras.
- Una publicación que comparte componentes de navegación y diseño con una aplicación Vue.
- Un sitio de marketing que contiene funciones de cuenta, búsqueda o personalización.
- Una base de conocimiento interna creada a partir de colecciones de contenido estructurado.
- Una propiedad con varias secciones que requiere reglas de renderizado diferentes para las rutas editoriales y de aplicación.
Nuxt Content no es por sí mismo un servicio editorial alojado. Los equipos aún deben evaluar los permisos de autor, los flujos de revisión, la gestión de medios, la localización, las vistas previas y los controles de publicación cuando personas no desarrolladoras mantienen el material.
Para un sitio de documentación modesto, el Markdown local puede ser suficiente. Una organización editorial grande podría preferir una plataforma de contenidos externa y seguir utilizando Nuxt para la presentación y el renderizado.
¿Quién mantiene Nuxt y dónde se reúne su comunidad?
Según la página oficial del equipo revisada el 27 de agosto de 2026, el desarrollo de Nuxt y su ecosistema está dirigido por un equipo internacional. La página enumera los equipos principales y del ecosistema; esta atribución a nivel de equipo es más fiable que inferir un único fundador a partir del historial del repositorio o de perfiles individuales.
El repositorio mantenido nuxt/nuxt de GitHub contiene el código fuente del framework, el registro de incidencias, material para contribuir y el historial de versiones. La actividad del repositorio puede ayudar a los desarrolladores a examinar la implementación y el mantenimiento, pero no debe tratarse como una promesa sobre calendarios futuros.
La página oficial de ayuda de la comunidad identifica dos vías de soporte relevantes:
- Discord es la vía oficial para conversar y recibir ayuda de la comunidad en tiempo real.
- GitHub Discussions es la vía oficial para preguntas que se benefician de un hilo asíncrono y consultable.
Nuxt explica que los participantes de la comunidad ofrecen su ayuda de forma voluntaria. Los proyectos que requieran tiempos de respuesta garantizados, trabajo privado de arquitectura o soporte contractual deben evaluar por separado el soporte profesional.
¿Cuándo es Nuxt una buena opción?
Nuxt es un candidato sólido cuando Vue ya es el modelo de componentes preferido y el proyecto necesita más que una interfaz ligera de navegador. Sus convenciones son especialmente valiosas cuando las páginas públicas, las funciones interactivas y los manejadores de servidor deben compartir una única estructura de aplicación.
Considera Nuxt cuando
- El equipo ya trabaja eficazmente con Vue.
- Las rutas públicas se benefician de HTML producido en el servidor o prerenderizado.
- Las páginas frontend y los endpoints de servidor modestos deben convivir.
- Las secciones de contenido y aplicación necesitan layouts y componentes compartidos.
- Diferentes grupos de rutas requieren políticas distintas de renderizado o caché.
- Los colaboradores prefieren una convención documentada en lugar de ensamblar muchas herramientas separadas.
Compara otros enfoques cuando
- El sitio es casi completamente estático y necesita poca interactividad de Vue.
- El equipo quiere una capa más pequeña del lado del cliente sobre un backend independiente ya establecido.
- Los desarrolladores requieren una estructura muy personalizada con pocas convenciones del framework.
- El entorno de ejecución previsto no puede proporcionar el comportamiento necesario de servidor o caché.
- La experiencia principal del proyecto con aplicaciones se encuentra en otro ecosistema de componentes.
La amplitud de Nuxt solo resulta útil cuando el proyecto la necesita. Un pequeño sitio informativo puede utilizar Nuxt, pero eso no demuestra que su motor de servidor y sus convenciones de aplicación sean la opción más sencilla.
¿Qué debe probar un equipo antes de elegir Nuxt?
Crea un corte vertical representativo y despliégalo en el entorno previsto. Incluye contenido real, un componente interactivo significativo, una solicitud al servidor y el límite de autenticación o datos esperado.
Utiliza esta secuencia de evaluación:
- Clasifica las rutas. Separa las rutas editoriales, públicas dinámicas, privadas y de endpoints de servidor.
- Asigna el renderizado de forma intencionada. Registra por qué cada clase es universal, del lado del cliente, prerenderizada o híbrida.
- Prueba la carga útil del navegador. El renderizado en el servidor por sí solo no controla la hidratación ni el coste de JavaScript.
- Utiliza un volumen de contenido realista. Mide las compilaciones y consultas con cantidades creíbles de páginas y colecciones.
- Verifica las funciones de despliegue. Confirma que el preset seleccionado admite la semántica necesaria de caché y regeneración.
- Revisa los límites del entorno de ejecución. Comprueba que los valores exclusivos del servidor no puedan entrar en el código del cliente.
- Prueba la comprensión de los colaboradores. Pide a un nuevo desarrollador que siga las rutas, las importaciones automáticas, el flujo de datos y los manejadores de servidor.
La pregunta práctica no es si Nuxt puede crear el proyecto. Es si la integración con Vue, las convenciones, la capa de servidor y los controles a nivel de ruta de Nuxt simplifican lo suficiente el trabajo predominante del proyecto como para justificar sus conceptos adicionales.
Una respuesta correcta no garantiza la seguridad. Las mediciones describen una observación puntual.