El futuro del tooling: hacia dónde va el build

Cierras el track mirando hacia adelante. El futuro del build frontend no es un misterio ni una lista de productos por venir: lo gobiernan dos vectores que ya están en marcha y que este track te ha enseñado a leer. El primero es Rust por todas partes: el sustrato nativo bajo un AST común colonizando cada herramienta, del linter al bundler al test runner. El segundo es la caché como rey: la constatación de que, agotada la carrera por compilar rápido, la victoria pasa a ser no compilar en absoluto. Proyectar estos dos vectores no es adivinar el futuro; es extrapolar tendencias que ya viste operar en cada nivel. Y de esa proyección sale una brújula estratégica: cómo mantenerte vigente sin agotarte persiguiendo cada herramienta nueva de la temporada.

Rust por todas partes

El primer vector es el reemplazo del sustrato. Durante quince años el tooling se escribió en el mismo lenguaje que servía: JavaScript. Era cómodo —una sola comunidad, un solo runtime— pero puso un techo de latencia que ningún algoritmo esquivaba, porque parsear, recorrer y emitir en un lenguaje interpretado, con un solo hilo y pausas de recolector, tiene un suelo de coste irreducible. esbuild en Go probó que bajar de sustrato daba 100x; Rust apuró el último orden de magnitud y, sobre todo, trajo algo que Go no podía: compartir el AST de Oxc entre todas las piezas.

flowchart LR
js[JavaScript: un hilo y GC] --> go[Go: compilado con GC]
go --> rust[Rust: sin GC y AST compartido]
rust --> conv[Un solo toolchain: Oxc Rolldown Vite Vitest]
style js fill:#f9e2af,color:#11111b
style rust fill:#fab387,color:#11111b
style conv fill:#a6e3a1,color:#11111b

La dirección es una convergencia, no una moda pasajera. Cada herramienta que se reescribe en Rust no solo gana velocidad: gana la posibilidad de compartir el mismo árbol con las demás. Ese efecto de red —cuantas más piezas comparten el AST, más vale unirse a ellas— es lo que vuelve el movimiento irreversible. El linter, el formateador, el transformador, el bundler y las pruebas dejan de ser cinco proyectos con cinco parsers y pasan a ser cinco vistas de un mismo árbol.

La caché como rey

El segundo vector es un cambio de meta. Mientras el sustrato bajaba de JavaScript a Rust, la frontera de la optimización se desplazó: agotada en buena parte la carrera por compilar más rápido, la siguiente ganancia grande no está en compilar mejor, sino en no compilar. El build más rápido es el que no ocurre.

La consecuencia estratégica es que la métrica de excelencia cambia. Un pipeline maduro ya no presume de lo rápido que compila, sino de cuánto logra no compilar: su tasa de cache hits, los paquetes que el affected deja fuera, los assets hasheados que el navegador ya tiene. Cachear bien, eso sí, es difícil: exige aislar cada tarea con inputs y outputs fieles, y una caché mal aislada se envenena y despliega bits equivocados en verde. Poder y peligro, como siempre en este oficio.

Hacia dónde va: el build invisible

Extrapola los dos vectores y verás hacia dónde apuntan juntos. Un sustrato nativo que borra la latencia y una caché que borra el trabajo repetido convergen en la misma dirección: el build tiende a volverse invisible. No desaparece —siempre habrá que convertir tu código en algo que el navegador cargue rápido—, pero deja de ser una espera que interrumpe tu trabajo para convertirse en un detalle que casi nunca notas.

Ninguna fila de esa tabla es una profecía arriesgada: las cuatro son la prolongación de una recta que ya viste trazarse a lo largo del track. El futuro no traerá una herramienta que rompa el patrón, sino más piezas que lo cumplan.