Qué es Vite: el dev server que no empaqueta · Build & Producción

Vite —se pronuncia como en francés, donde significa rápido— nombra con una sola palabra su promesa: arrancar de inmediato. Debajo late una idea sorprendentemente simple y, a la vez, radical: en desarrollo, no empaquetar nada. En lugar de compilar tu proyecto entero en un solo archivo antes de dejarte trabajar, Vite se apoya en que el navegador moderno ya sabe cargar módulos por sí mismo, y le sirve tu código pieza a pieza, según lo va pidiendo. De esa inversión se deriva todo lo demás que estudiarás en este nivel.

🎯 Al terminar esta lección sabrás

Definir Vite como un servidor de desarrollo que sirve ESM nativo sin empaquetar.
Contrastar el modelo bundle-first clásico con el modelo bajo demanda de Vite.
Entender por qué el arranque en frío es independiente del tamaño del proyecto.
Situar Vite como dos herramientas —dev y build— reunidas bajo un mismo nombre.

Un servidor que habla el idioma del navegador

Desde 2015 todo navegador entiende módulos ESM de forma nativa a través de <script type="module">. Cuando el motor encuentra un import, no bloquea ni adivina: emite una petición HTTP por ese módulo concreto y espera la respuesta.

El navegador es, ya de fábrica, un cargador de módulos. La tesis de Vite es aprovechar ese hecho en lugar de suplantarlo.

Todo arranca en el documento. El navegador pide index.html y encuentra en él una única puerta de entrada al código:

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>

Vite es, literalmente, ese servidor. No construye un bundle de tu aplicación: cuando el navegador pide un archivo, Vite lo transforma al vuelo y devuelve ESM que el motor acepta sin más.

Esa transformación al vuelo hace tres cosas por cada archivo:

Borra los tipos de TypeScript, porque el motor jamás los ha visto.
Convierte el JSX en llamadas a funciones ordinarias.
Reescribe los bare specifiers —los import a paquetes por su nombre— a rutas que el navegador sí sabe resolver.

// Lo que escribes en src/main.tsx
import { montar } from "./app.tsx";
import confetti from "canvas-confetti";

// Lo que Vite devuelve: rutas que el motor sabe resolver
import { montar } from "/src/app.tsx";
import confetti from "/node_modules/.vite/deps/canvas-confetti.js";

flowchart TB
subgraph Navegador
  n1[pide el html]
  n2[lee un import]
  n3[pide el modulo]
  n4[ejecuta el codigo]
end
subgraph Vite
  v1[sirve el html]
  v2[transforma al vuelo]
end
n1 --> v1
v1 --> n2
n2 --> n3
n3 --> v2
v2 --> n4
style n1 fill:#89b4fa,color:#11111b
style v2 fill:#a6e3a1,color:#11111b
style n4 fill:#cba6f7,color:#11111b

El navegador tira del hilo. Pide el punto de entrada, lee sus import, pide esos módulos, lee los suyos, y así recorre el grafo por su cuenta.

Vite se limita a responder cada petición transformando un único archivo. Nunca ve el grafo completo de golpe, y nunca lo necesita.

El arranque no depende del tamaño

Aquí está la diferencia que lo cambia todo. Un empaquetador clásico —webpack a la cabeza durante una década— es bundle-first: antes de servir el primer byte, recorre el grafo entero desde la raíz, transforma cada módulo y los cose en un paquete que mantiene en memoria.

Ese trabajo es proporcional al tamaño del proyecto. En una aplicación grande, arrancar el servidor podía costar decenas de segundos, y crecía sin remedio a medida que sumabas código. El tiempo de arranque se convertía en un impuesto que pagabas mil veces al día.

Vite invierte el orden. El servidor está listo casi al instante porque, al arrancar, no compila casi nada: solo entrega index.html.

npm create vite@latest mi-app
cd mi-app && npm install
npm run dev   # el servidor esta listo casi al instante

El trabajo de transformar módulos ocurre después, bajo demanda, y solo para los archivos que la ruta actual importa de verdad. Si depuras una pantalla que toca veinte módulos, pagas por veinte, no por los dos mil de la aplicación entera.

🐌

Modelo bundle-first

Construye el paquete completo antes de servir. El coste de arranque es proporcional al tamaño del proyecto y crece sin techo.

⚡

Modelo bajo demanda

Sirve al instante y transforma cada módulo cuando el navegador lo pide. El coste es proporcional a lo que la página usa ahora.

El cambio no es de grado, es de naturaleza. El arranque en frío deja de ser una función del tamaño del código para convertirse en una constante.

Da igual que el repositorio tenga cien archivos o cien mil: el servidor responde igual de rápido. Esa independencia del tamaño es la propiedad que hizo a Vite viable en proyectos serios y la razón por la que desplazó a webpack en desarrollo.

Qué es Vite y qué no es

Conviene fijar la definición con precisión, porque Vite se malinterpreta a menudo. Vite no es un empaquetador que corre rápido en desarrollo: es un servidor que evita empaquetar.

Tampoco es un framework —no impone componentes ni enrutado— sino una capa de tooling sobre la que Vue, React, Svelte, Solid o Astro se apoyan por igual.

Y no reemplaza al navegador como cargador de módulos: lo usa. En una frase, Vite es un orquestador delgado, y lo que hace y lo que delega se reparte así:

Delega en el navegador el recorrido del grafo de módulos.
Delega en motores nativos la transformación pesada de cada archivo.
Se reserva reescribir los import a rutas que el navegador pueda resolver.
Se reserva servir cada módulo con el tipo MIME correcto y con caché.

ℹ️

Vite se apoya en motores nativos por debajo

Vite no transforma el código en JavaScript puro: para las tareas pesadas orquesta motores nativos, mucho más rápidos que cualquier herramienta escrita en JavaScript. Durante años usó esbuild, escrito en Go, para el pre-bundling de dependencias, y Rollup, en JavaScript, para el empaquetado de producción. En 2026, Vite 8 unifica ambos papeles en Rolldown, un bundler en Rust. Esa capa por debajo es la que estudiarás en la última lección de este nivel; por ahora basta con retener que Vite es un orquestador delgado sobre motores veloces.

Vite ya son dos herramientas

Conviene fijar desde el principio un matiz que desarrollaremos en la lección de las dos mitades: no empaquetar es la estrategia de desarrollo, no la de producción.

Cuando ejecutas vite, levantas el servidor de ESM sin bundle. Cuando ejecutas vite build, Vite sí produce un paquete optimizado —minificado, con tree shaking y code splitting— porque servir cientos de módulos sueltos por la red a un usuario real sería lentísimo.

Un mismo vite.config.ts gobierna ambos mundos, pero cada uno elige el compromiso opuesto.

vite          # servidor de desarrollo: ESM nativo, sin empaquetar
vite build    # produccion: un bundle optimizado en dist/
vite preview  # sirve dist/ para inspeccionar el resultado real

⚡

La inversión conceptual que define a Vite

Durante quince años, la industria del frontend asumió una premisa que parecía ley de la física: para poder ejecutar tu código en desarrollo, primero hay que compilarlo entero. Toda la lentitud del tooling de los años diez —esos arranques eternos, esos rebuilds que crecían con el proyecto— era el precio aceptado de esa premisa. La aportación de Vite no fue optimizar el empaquetado, sino cuestionar que hiciera falta empaquetar en desarrollo. La pregunta que lo destrabó todo fue: si el navegador ya sabe cargar módulos, ¿por qué construimos un bundle solo para dárselo entero? Al soltar esa suposición, el coste de arranque se desacopló del tamaño del proyecto y el modelo mental se alineó con cómo la web carga de verdad. Entender Vite no es memorizar banderas de configuración: es interiorizar esta inversión. Todo lo que viene después —el HMR quirúrgico, el pre-bundling de dependencias, la arquitectura de dos mitades, la llegada de Rolldown— son consecuencias o refinamientos de haber dejado de empaquetar en desarrollo. Quien capta esta idea deja de ver Vite como una herramienta y empieza a verlo como una tesis sobre cómo debería sentirse programar para la web.

⚔️ Comprueba que el navegador es quien tira del hilo

Crea un proyecto con npm create vite@latest, ejecútalo y abre la pestaña de red del navegador: observa cómo cada módulo llega como una petición HTTP independiente.
Añade un import a un módulo nuevo y confirma que aparece una petición nueva solo cuando esa ruta lo necesita.
Cronometra el arranque de vite; añade veinte archivos más al proyecto y vuelve a cronometrarlo: comprueba que el tiempo apenas se mueve.
Ejecuta vite build y compara: ahora sí hay un paso de empaquetado, y el resultado en dist/ no son módulos sueltos sino un paquete. Esa diferencia es el tema del resto del nivel.