Portar React Compiler a Rust

Uso de React Compiler y rendimiento en el mundo real

• Varios comentaristas informan que usan React Compiler en producción (p. ej., grandes sitios de comercio electrónico/medios, la UI de Unifi, aplicaciones de tamaño moderado).
• Beneficios reportados: un rendimiento de renderizado notablemente mejor, capacidad para eliminar la mayoría de memo/useMemo/useCallback sin regresiones, y mejor rendimiento que configuraciones anteriores con Preact en al menos un caso.
• Inconvenientes: tiempos de compilación más altos, aunque algunos consideran aceptables los tiempos de compilación con bundlers modernos; la incompatibilidad con ciertas bibliotecas (p. ej., MobX) llevó al menos a una empresa a revertir el cambio, ya que además no vieron una ganancia clara de rendimiento en una base de código existente.

Memoización automática y seguridad

• Algunos son escépticos respecto a la memoización automática debido al riesgo de regresiones sutiles de rendimiento y dependencias ocultas.
• Otros describen buenas experiencias: las reglas de ESLint señalan código no optimizable o que no cumple con los hooks, las bibliotecas incompatibles se excluyen automáticamente, y la memoización generada por el compilador es más granular y menos propensa a errores que los patrones manuales.
• Se sugiere usar herramientas como el playground en línea del compilador para inspeccionar cómo se transforma el código.

Por qué Rust y cómo funciona el port

• El compilador actual estaba en TypeScript / Flow; Rust se ve como una forma de ganar velocidad, binarios nativos, paralelización más sencilla e independencia de los runtimes de JS.
• La seguridad de memoria se reconoce como una ventaja, pero la mayoría ve el rendimiento bruto y el tiempo de arranque como la motivación principal.
• Se usan arenas como reemplazo del GC; algunos lo ven conceptualmente simple más que como una complejidad añadida.

Diseño del AST: Babel frente a Oxc

• Algunos cuestionan por qué el port a Rust conserva un AST parecido al de Babel en lugar de adoptar el AST de Oxc.
• Quienes lo defienden argumentan: hay múltiples consumidores, el equipo ya construyó lógica en torno a la representación de Babel, y solo quieren mantener una conversión compleja de AST→HIR. Las limpiezas a nivel de ecosistema pueden llegar después.

Port a Rust asistido por LLM: confianza, pruebas y mantenibilidad

• Muchos asumen que el port estuvo fuertemente asistido por LLM y ven esto como una buena combinación para reescrituras mecánicas cuando existe una sólida suite de pruebas.
• Quienes lo apoyan: si pasa miles de pruebas (más las nuevas) y las APIs públicas no cambian, es una victoria pragmática; los LLM destacan en el ciclo iterativo de “comparar resultados, corregir, repetir”.
• Escépticos: los PRs de 120k líneas son casi imposibles de revisar para humanos; que “las pruebas pasen” puede ocultar huecos; el trabajo futuro sobre nuevas funciones podría ser arriesgado si pocos humanos entienden a fondo el código.
• Preocupaciones sobre la “deuda cognitiva” y una tendencia en la que las bases de código solo se vuelven efectivamente mantenibles con ayuda de LLM.

Proceso, revisiones y reflexiones más amplias

• Algunos se preocupan por los PRs grandes con revisión visible limitada y menos RFC públicas que en hitos anteriores de React.
• Otros responden que la elección del lenguaje es un detalle de implementación, y que el contrato público de React sigue siendo estable.
• Debate más amplio: lenguajes dinámicos frente a estáticos, herramientas nativas Java/.NET frente a Go/Rust, y si los LLM reducen o “eliminan” la barrera para usar lenguajes complejos como Rust.