El problema: una app moderna vive en varios entornos

Tu aplicación no se ejecuta en un solo lugar. El mismo código fuente termina corriendo en el navegador, en un servidor Node que genera el HTML inicial y, cada vez más, en un runtime del edge —workerd, Deno, Bun— que imita las Web APIs del navegador pero no es Node. Cada destino es un runtime distinto: otros globales, otras condiciones de resolución, otras restricciones. Durante años, Vite modeló ese mundo plural como un binario: un grafo de cliente y un único grafo de SSR. Todo lo demás fue un parche. Este nivel diagnostica por qué ese binario tenía que romperse.

Un mismo código, muchos destinos

Una aplicación web moderna no es un programa, sino varios recortados del mismo fuente. Los mismos componentes se renderizan en el navegador —con document, window y el fetch del DOM—, en un servidor Node que produce el HTML inicial mediante SSR y, con frecuencia creciente, en un runtime del edge: Cloudflare workerd, Deno o Bun, que exponen las Web APIs estándar pero no son Node y no traen sus módulos node: de serie.

Cada destino es un runtime con su propia física. Cambian los globales disponibles, cambian las condiciones de resolución que deciden qué archivo de un paquete se importa —browser, node, worker, edge— y cambian las restricciones: en el edge no hay sistema de archivos ni hilos, y un import de node:fs que en el servidor es trivial allí sencillamente no existe. La herramienta de build tiene que producir y servir código para todos esos destinos desde una sola base de código y, esto es lo decisivo, hacerlo idéntico en desarrollo y en producción.

La palabra clave es paridad. No basta con que el código funcione en cada destino por separado; hace falta que la representación que pruebas en tu máquina sea la misma que se despliega. Cuando el runtime de desarrollo difiere del de producción, cada diferencia —un global ausente, una condición que resuelve a otro fichero, una API con semántica distinta— se vuelve un bug latente que solo aflora tras el despliegue, en el peor momento y con el peor coste de diagnóstico.

Conviene contar los destinos con los dedos, porque el número exacto importa: no es “cliente y servidor”, es cliente, uno o varios servidores Node, uno o varios Workers de edge y, cuando entran los RSC, grafos de servidor que coexisten. La pregunta deja de ser binaria —¿cliente o servidor?— y se vuelve cardinal: ¿cuántos entornos distintos, con qué runtime cada uno? Una herramienta que solo sabe contar hasta dos no puede responder esa pregunta, y todo el nivel trata de cómo Vite aprendió a contar más allá.

Vite 5: dos grafos cableados

Vite creció con un modelo de dos mundos. Por dentro mantenía exactamente dos grafos de módulos, cableados en el código: el grafo client —lo que el navegador carga por ESM nativo— y un único grafo ssr —lo que Node evalúa para generar HTML—. La superficie pública reflejaba ese binario sin disimulo.

// Vite 5: el mundo era binario, y estaba cableado en el objeto server
server.moduleGraph                                  // EL grafo del cliente
await server.transformRequest(url)                  // transform de cliente
await server.transformRequest(url, { ssr: true })   // transform de SSR
await server.ssrLoadModule('/src/entry-server.ts')  // evaluado SIEMPRE en Node

No existía un tercer hueco. “SSR” no era un concepto general de “un entorno de servidor cualquiera”: era ese grafo concreto, cableado para Node, incrustado en el objeto server. ssrLoadModule evaluaba el módulo con el sistema de módulos de Node y sus globales; daba por sentado el runtime. La palabra environment ni siquiera figuraba en la API: había cliente, y había SSR, y SSR quería decir Node. Cuando tu destino no era Node, la abstracción no te ofrecía nada y tenías que salirte de ella.

Merece detenerse en la palabra “cableado”, porque no es casual. Los dos grafos no eran configuración que pudieras extender: eran estructuras fijas del objeto server, con nombres propios en la API pública. Añadir un tercero no era pasar una opción, sino modificar el núcleo de Vite. Esa rigidez —dos y solo dos, por construcción— es la que forzó a todo el ecosistema a trabajar alrededor de Vite en vez de a través de él en cuanto el destino no era ni el navegador ni Node.

Por qué dos no bastan

Tres fuerzas quebraron el binario a la vez, y conviene verlas juntas porque comparten una misma raíz: el número de entornos reales dejó de ser dos.

flowchart TB
src[Codigo fuente unico] --> cl[Grafo client navegador]
src --> sr[Grafo ssr Node]
sr -. no encaja .-> ed[Edge workerd]
sr -. no encaja .-> rc[RSC server]
sr -. no encaja .-> wq[Worker de cola]
style cl fill:#89b4fa,color:#11111b
style sr fill:#f9e2af,color:#11111b
style ed fill:#f38ba8,color:#11111b
style rc fill:#f38ba8,color:#11111b
style wq fill:#f38ba8,color:#11111b

• El edge no es Node. ssrLoadModule evalúa en Node, con sus globales y su resolución. Para correr ese mismo código de servidor dentro de workerd durante el desarrollo, los frameworks no podían reutilizarlo: dev corría en Node y producción en el edge, una brecha de paridad que escondía bugs hasta el despliegue.
• Una app puede tener varios servidores. Un proyecto real combina a veces un worker de SSR con un worker de cola, o varios Workers coordinados. Dos grafos no pueden representar N contextos de servidor distintos, cada uno con su propia resolución y sus propios plugins.
• Los RSC exigen tres grafos. React Server Components necesita como mínimo tres: el grafo de servidor que ejecuta los componentes de servidor, el de SSR que los hidrata a HTML y el de cliente, cada uno con su transform y sus condiciones. Un único hueco ssr no puede albergar dos grafos de servidor diferentes a la vez.

El coste de segundo orden se pagaba a diario, y era el HMR. Cuando empaquetabas el servidor y lo reimportabas para ejecutarlo, perdías la actualización en caliente y volvías al ciclo de reinicio completo; cuando levantabas un servidor de Vite aparte, tenías que reinventar el puente que propaga los cambios de un grafo al runtime. El desarrollo del lado servidor iba siempre un peldaño por detrás del confort que Vite había normalizado para el cliente.

Hay un matiz que agrava el cuadro: estos tres frentes no son alternativos, sino acumulativos. Una app real de 2026 puede ser, a la vez, cliente en el navegador, SSR en Node para el HTML inicial, RSC en un grafo de servidor y una función en workerd para una ruta de API. No es que elijas uno de los casos difíciles; es que te tocan varios a la vez, y el modelo de dos casillas se queda sin sitio ya en el segundo destino que no encaja en ellas.

El coste de vivir sin entornos

Vale la pena catalogar los parches, porque cada uno reaparecerá, ya resuelto, cuando lleguemos a la Environment API. Todos compartían una misma forma: reimplementar, fuera de Vite, una porción del trabajo que Vite hacía para el cliente pero se negaba a generalizar al resto de destinos.

// El rodeo tipico: un segundo servidor de Vite solo para el codigo de servidor
const clientServer = await createServer(clientConfig)
const ssrServer = await createServer(ssrConfig)   // otra instancia, otro proceso mental
const { render } = await ssrServer.ssrLoadModule('/src/entry-server.ts')

Ninguno de estos rodeos era ilegítimo; todos eran respuestas razonables a una herramienta que no modelaba el problema. Pero su suma era un ecosistema fragmentado: cada framework mantenía su propia máquina, incompatible con la del vecino, y un plugin escrito para uno no servía para otro. La energía que debería haber ido a mejorar la plataforma se disipaba en reconstruir, una y otra vez, el mismo andamiaje.

flowchart TB
prob[El mismo problema ejecutar codigo de servidor] --> a[Framework A con su runner]
prob --> b[Framework B con su runner]
prob --> c[Framework C con su runner]
a --> dup[trabajo duplicado e incompatible]
b --> dup
c --> dup
style prob fill:#f9e2af,color:#11111b
style dup fill:#f38ba8,color:#11111b

El dibujo delata el desperdicio: varios frameworks resolviendo, cada uno por su cuenta, el mismo problema de ejecutar código de servidor, y produciendo soluciones que no se hablan entre sí. No es solo trabajo duplicado; es trabajo divergente, porque cada runner improvisado tomaba decisiones ligeramente distintas sobre resolución, globales o HMR, y esas diferencias se filtraban a los usuarios como incompatibilidades sutiles y difíciles de rastrear.

El diagnóstico que cristalizó en la comunidad fue quirúrgico: el problema no era ninguno de los parches en particular, sino la suposición que los hacía necesarios —que “no cliente” equivale a “un único SSR de Node”—. Mientras esa suposición viviera cableada en el server, cada nuevo destino exigiría un nuevo rodeo. La única cura de fondo era mover el concepto de entorno de “constante del núcleo” a “abstracción de primera clase, pluralizable y configurable”.