El compilador de React pasa a Rust, y Next.js 16.3 ya puede usarlo

El equipo de React ha reescrito el compilador de React en Rust, y los resultados empiezan a notarse en los tiempos de compilación reales. El puerto a Rust llegó al monorepo de React a principios de junio (PR #36173), y Vercel lo integró en Turbopack unas semanas después. En Next.js 16.3 ahora puede optar por el compilador nativo y omitir por completo el antiguo camino de Babel.

Un repaso rápido para quienes no lo hayan usado: el compilador de React (antes llamado React Forget) memoiza automáticamente sus componentes y hooks, para que deje de escribir useMemo y useCallback a mano. Ha sido estable en Next.js desde la versión 16.0. El problema era cómo se ejecutaba. Como transformación de Babel añadía sobrecarga de ejecución de JavaScript en cada compilación, y en aplicaciones grandes eso se convertía en un cuello de botella real mientras el pipeline de Rust de Turbopack esperaba ocioso.

Qué fue lo que se aceleró

La reescritura en Rust cambia la ecuación. El equipo de React informa que el puerto funciona unas 3 veces más rápido como plugin de Babel, y hasta 10 veces más en la lógica de transformación aislada. La mayor ventaja llega cuando el compilador deja de ser un plugin. Enlazado directamente en Turbopack, Andrew Imm de Vercel midió una compilación más de un 40% más rápida en v0, su propia aplicación grande de Next.js, en parte porque el camino anterior del plugin de SWC sufría de un arranque en frío lento de WebAssembly. Las cifras oficiales de Next.js sitúan la mejora en un 20 a un 50% de compilación de rutas más rápida en sus aplicaciones de prueba.

Una advertencia honesta antes de emocionarse: esto es experimental, y el equipo de React catalogó el propio puerto como un trabajo en curso. La arquitectura fue guiada por humanos pero, según el propio autor, escrita principalmente por IA. Todos los casos de prueba del compilador pasan y la salida coincide con la versión de TypeScript en el 99,9% del código base de Meta. Pero el 99,9% no es el 100%, y es opt-in por una razón.

Cómo lo desplegaríamos

Cuando desarrollamos aplicaciones nativas en la nube para clientes empresariales, un cambio de compilador o empaquetador es exactamente el tipo de cambio que parece gratuito y luego se come un sprint. Trátelo como un ejercicio de medición, no de fe.

Actívelo en una rama, no en su pipeline de compilación principal. En Next.js 16.3 los indicadores son explícitos: establezca reactCompiler: true y experimental.turbopackRustReactCompiler: true, y recuerde que solo afecta al camino de Turbopack, no a --webpack. Luego haga un benchmark de su propia aplicación. El rango del 20 al 50% es el número de Vercel en las aplicaciones de Vercel. Su ganancia depende de cuánto use el compilador en sus componentes y de cuán fría empiece su caché de CI.

La parte que vigilaríamos con más atención es la paridad de salida. Un compilador que memoiza de forma ligeramente diferente puede cambiar el comportamiento de renderizado de maneras que sus pruebas unitarias no detectan. De nuestro trabajo con PHP y Docker hemos aprendido a fijar las versiones de la cadena de herramientas en CI y comparar la salida de compilación entre el camino antiguo y el nuevo antes de publicar. Haga lo mismo aquí: ejecute su suite completa de extremo a extremo en el camino de Rust, compare la salida del bundle y mantenga el camino de Babel como reversión de un solo indicador hasta que confíe en él.

La señal más amplia

Hay una tendencia de segundo orden que vale la pena nombrar. Esto forma parte de un movimiento constante de las herramientas de frontend hacia Rust. SWC ahora compila con el compilador oficial de Rust, Oxc lo distribuye como crates y Rspack 2.1 añadió soporte nativo. No todos los intentos han sido limpios; el mantenedor de Rolldown retiró su integración del compilador de React en Rust para ordenarla primero, por lo que la transición no ha terminado. Pero la dirección está marcada. Si sus herramientas de compilación son un montón de loaders personalizados de Webpack y requires dinámicos, esa deuda se va a hacer más cara de mantener.

Los equipos de móviles tampoco deberían ignorar esto. En nuestros proyectos nativos y de React Native el mismo patrón se mantiene: el compilador también funciona allí, y los tiempos de compilación predecibles importan aún más cuando su CI ya está gestionando cadenas de herramientas nativas. Y en cuanto a la seguridad, de nuestros trabajos de pentesting la lección es aburrida pero real. Cada nueva dependencia de compilación es nueva superficie de cadena de suministro. Un compilador experimental, asistido por IA, en su pipeline merece una revisión de dependencias, no una instalación ciega.

Una cosa que hacer hoy

Incluso si nunca activa el indicador de Rust: si está en Next.js y aún no usa el compilador de React, esa es la mayor oportunidad perdida. Active reactCompiler en una rama, elimine un lote de llamadas manuales a useMemo y useCallback, y mida el impacto en el renderizado y la compilación. El puerto a Rust simplemente hace que ese camino sea más barato de adoptar más adelante, una vez que salga de experimental.

Si perseguir tiempos de compilación o desenredar un crate de configuración de empaquetador personalizado le suena familiar, hablemos. Ayudamos a equipos web y móviles a publicar más rápido sin apostar producción en un indicador experimental.