Cuándo usar cada uno y la visión unificada de VoidZero

Después de cuatro lecciones diseccionando esbuild, SWC y Oxc por separado, toca la pregunta práctica: cuándo usas cada uno. La respuesta honesta desafía la propia pregunta, porque casi nunca eliges el motor de forma directa. Eliges un framework —Next.js, Vite, Astro— y heredas su toolchain. Esta lección ordena a los tres actores según el papel que juegan, muestra que la decisión real se toma una capa más arriba, y explica hacia dónde converge todo: VoidZero, la apuesta por un único toolchain en Rust con Oxc en el cimiento y Rolldown como bundler.

Tres actores, tres papeles

El error de partida es imaginar a esbuild, SWC y Oxc corriendo una misma carrera. No compiten en el mismo terreno: cada uno tiene una forma distinta y ocupa un lugar distinto.

• esbuild (Go). Un producto terminado, bundler y transformador a la vez, que invocas directamente o que otras herramientas incrustan. Sostuvo la mitad de dev de Vite durante años y sigue vivo en scripts, librerías y utilidades.
• SWC (Rust). Un motor de transpilación pensado para incrustarse. Vive dentro de Next.js —el Compiler— y de Rspack. Rara vez lo invocas tú; lo hereda tu framework.
• Oxc (Rust). Un toolchain completo bajo un solo AST: parser, resolver, oxlint, oxfmt, transformador y minificador. Es la base sobre la que se construye Rolldown.

# Que papel juega cada uno, y como lo obtienes
esbuild  ->  producto todo-en-uno en Go,    lo invocas o lo incrustan
SWC      ->  motor de transpilacion en Rust, vive en Next y en Rspack
Oxc      ->  toolchain completo en Rust,     base de Rolldown y Vite 8

Puestos así, se ve que la pregunta cuál es el mejor está mal planteada, como preguntar si es mejor un motor de coche o un coche entero. esbuild es un producto, SWC un componente y Oxc una plataforma; comparar sus velocidades brutas ignora que resuelven problemas distintos en capas distintas. La comparación útil no es cuál corre más, sino cuál encaja en el hueco que tienes delante.

Más aún, los tres conviven sin excluirse. Una misma máquina puede tener esbuild transpilando un script de utilidades, SWC dentro de una app Next heredada y Rolldown sobre Oxc en el proyecto Vite del equipo. No es una elección única para toda tu vida, sino la respuesta correcta para cada contexto, y esa respuesta cambia con el proyecto que tengas delante.

No eliges el motor, eliges el framework

De ese reparto se sigue la guía práctica más útil, y es contraintuitiva: en la inmensa mayoría de los casos no decides el motor de bajo nivel, decides una herramienta de más arriba y heredas el motor que trae. Si adoptas Next.js, obtienes SWC de forma transitiva. Si adoptas Vite 8 o Astro, obtienes Rolldown sobre Oxc. Si necesitas empaquetar una librería o correr un script rápido, ahí sí alcanzas esbuild de forma directa. Y si quieres lintar o formatear a velocidad nativa hoy, adoptas oxlint y oxfmt a la carta, sin comprometerte con nada más.

Reducida a una tabla mental, la decisión se toma casi sola:

• Empaquetar una librería o un script suelto hacia esbuild, directo y sin ceremonias.
• Una app con Next.js hacia SWC, que ya viene dentro y no configuras.
• Una app con Vite 8 o Astro hacia Rolldown sobre Oxc, heredado al actualizar.
• Lintar o formatear ya, en cualquier proyecto hacia oxlint y oxfmt, a la carta.

Ninguna de estas filas te obliga a estudiar el motor: basta con reconocer en qué fila estás.

Esta inversión es liberadora una vez la asimilas. Deja de tener sentido angustiarse por elegir el motor correcto, porque esa decisión ya la tomó, con más contexto que tú, el equipo del framework que usas. Tu energía se emplea mejor en elegir bien el framework —por su modelo mental, su ecosistema, su comunidad— y en confiar en que la mejora del motor llegará por debajo, versión a versión, sin pedirte nada. El motor es infraestructura; el framework es la decisión que de verdad importa.

Hay una excepción sana a esta regla, la del ingeniero de herramientas. Alguien tiene que construir el framework, elegir su motor y empujar la frontera; si ese eres tú, entonces sí eliges el motor, y este nivel te ha dado el mapa para hacerlo con criterio. Pero para la enorme mayoría —quienes construimos productos sobre esos frameworks— la sofisticación consiste en no confundir las dos capas y en no reimplementar decisiones que otros ya tomaron con más contexto.

VoidZero: un solo toolchain en Rust

Los caminos que acabas de ver no son independientes: convergen en un mismo punto. VoidZero es la empresa fundada por el creador de Vite con una misión explícita: reunir todo el tooling de JavaScript en una única base en Rust, coherente y sin costuras. Sus piezas encajan como los órganos de un mismo cuerpo. Oxc aporta las utilidades de lenguaje —parser, resolver, linter, formateador, transformador, minificador—. Rolldown es el bundler que las coordina. Vite es el dev server y el pegamento de framework. Y Vitest es el test runner. Todas comparten el mismo AST y la misma velocidad nativa.

La cronología ayuda a situarlo. Vite nació resolviendo el dev server; Vitest extendió esa base a las pruebas; Rolldown y Oxc llegaron para sustituir los motores prestados —esbuild y Rollup— por piezas propias en Rust. VoidZero es el nombre que ese esfuerzo tomó al constituirse en empresa, con financiación y equipo dedicados, porque unificar un toolchain entero excede lo que un proyecto de fin de semana puede sostener.

flowchart TB
subgraph VoidZero
  oxc[Oxc parser resolver linter formatter transform minify]
  rolldown[Rolldown el bundler] --> oxc
  vite[Vite dev server y build] --> rolldown
  vitest[Vitest el test runner] --> vite
end
style oxc fill:#a6e3a1,color:#11111b
style rolldown fill:#89b4fa,color:#11111b

La consecuencia para ti es que el mismo entendimiento de tu código fluye del editor al dev server, del dev server al bundle y del bundle a las pruebas. Un solo AST, una sola semántica, de principio a fin. Hasta ahora, ese recorrido cruzaba varias fronteras: el editor usaba un parser, el bundler otro, el test runner uno más, y cada frontera era una ocasión para que dos herramientas discreparan sobre qué era tu programa. VoidZero apuesta a que esas fronteras internas desaparezcan, de modo que probar, empaquetar y analizar sean vistas distintas de un mismo árbol y no traducciones sucesivas del mismo texto.

Conviene fijar qué hace cada órgano, porque juntos forman el aparato completo:

• Oxc — las utilidades de lenguaje: parser, resolver, linter, formateador, transformador y minificador.
• Rolldown — el bundler que coordina esas utilidades para producir el artefacto final.
• Vite — el dev server y la capa de integración con los frameworks.
• Vitest — el test runner que corre tus pruebas sobre el mismo análisis del código.

Que una sola organización sostenga las cuatro piezas no es un detalle corporativo, sino la condición que hace posible la coherencia. Cuando el mismo equipo diseña el parser y el bundler que lo usa, puede garantizar que encajan; cuando son proyectos independientes que se coordinan a duras penas, las junturas se abren. La unificación técnica necesitaba también una unificación de propósito, y eso es lo que VoidZero aporta.

Los beneficios de que todo comparta base se acumulan:

• Una sola capa de análisis en vez de cinco parsers que mantener por separado.
• El mismo diagnóstico del código en el editor, en el bundler y en las pruebas.
• Mejoras de velocidad que se propagan a la vez a todas las piezas de la familia.

Rolldown sobre Oxc y el futuro

Rolldown es la pieza que ata el nudo. Toma las utilidades de Oxc y las convierte en un bundler completo; Vite 8 lo trae por defecto, así que la unificación llega a millones de proyectos sin que nadie la pida. La fragmentación de la década anterior —cada herramienta con su propio parser, su propia semántica y sus propias grietas— cede el paso a una base común en Rust con un único árbol.

Para ti, en la práctica, esa convergencia se traduce en cosas concretas:

• Builds de producción mucho más rápidos, al ser el motor nativo.
• Paridad entre dev y build, porque el mismo árbol recorre las dos mitades.
• Un linter y un formateador de la misma familia, adoptables por separado.
• Cero configuración nueva: la mejora entra al actualizar el framework.

Ninguno de esos cuatro puntos te pide una acción especial: son lo que recibes, gratis, por estar en el lado del ecosistema que se unificó.

# En 2026, adoptar la base unificada es casi transparente
pnpm up vite@8            # Rolldown sobre Oxc entra como motor por defecto
npx oxlint@latest        # el linter de la misma familia, a la carta

Visto en perspectiva, la secuencia es nítida: esbuild probó que un lenguaje nativo cambiaba el orden de magnitud; SWC probó que un motor en Rust podía colonizar el ecosistema desde dentro; Oxc generalizó esa tesis a toda la cadena bajo un AST; y VoidZero la está ensamblando en un solo organismo. No es la historia de una herramienta ganando a otra, sino la de un oficio que deja de estar hecho de retales.

# La convergencia, en una linea de tiempo
esbuild  ->  probo que el lenguaje nativo cambia el orden de magnitud
SWC      ->  probo que un motor en Rust coloniza el ecosistema desde dentro
Oxc      ->  unifico toda la cadena bajo un solo AST compartido
VoidZero ->  ensambla Oxc Rolldown Vite y Vitest en un mismo organismo

Queda una pregunta legítima: qué pasa si la apuesta falla, si VoidZero no completa la torre. Aquí la estrategia de interfaces vuelve a protegerte. Aunque el proyecto tropezara, Rolldown conserva la API de Rollup, oxfmt conserva el estilo de Prettier y oxlint corre sobre tu código sin atarte a nada. Adoptar estas piezas no es firmar un cheque en blanco por una visión, sino aprovechar herramientas que ya ganan hoy y que, si la visión se cumple, te habrán colocado sin esfuerzo en el lado correcto de la historia.