React JS

TanStack Redact reemplaza el runtime de React por uno síncrono y 66% más liviano: úsalo solo si tu app no depende del renderizado concurrente.

Qué es TanStack Redact y por qué aparece ahora

React no es solo una librería de componentes: es un runtime con un planificador que decide cuándo interrumpir, reanudar y priorizar trabajo. Redact conserva la API que ya conoces —componentes, hooks, JSX— pero sustituye ese motor por uno más simple y más pequeño. En la práctica cambias la pieza que interpreta tu árbol de componentes, no la forma en que lo escribes.

Aparece ahora porque el costo del JavaScript de framework dejó de ser un detalle de laboratorio. Cuando un equipo revisa Core Web Vitals, una parte del tiempo de bloqueo del hilo principal viene del propio runtime, no de tu lógica de negocio. Redact ataca esa porción: la que no cambia entre proyectos.

TanStack mantiene integraciones estables (rama 0.2.x) para TanStack Start, Vite, Vinext y Next.js, y un preset llamado nano que baja hasta 12.466 bytes gzip. Hay rutas de adopción probadas, aunque el proyecto sigue en versiones tempranas. La comunidad lo puso en el radar esta semana: los boletines This Week In React (#304) y el roundup del 9 de noviembre de 2026 lo señalaron como un desarrollo a evaluar con cuidado, no como un reemplazo inmediato. Ese matiz es el correcto.

Cuánto pesa de verdad tu runtime de React

Antes de tocar nada, mide. El error más común es comparar números de internet con un bundle que no se parece al tuyo. Los bytes que importan son los que salen de tu build, con tu configuración y tus dependencias.

# Node 20+, Vite 5+
npm run build
npx vite-bundle-visualizer

Ese comando abre un treemap del bundle final. Busca ahí react-dom y react: eso es lo que Redact reemplazaría. Todo lo demás —tu código, librerías de terceros, iconos, CSS-in-JS— se queda igual, así que el ahorro real es ese bloque, no el total del archivo.

Para verlo en bytes comprimidos, revisa la salida del build:

# Suma el tamaño gzip de todos los chunks generados
gzip -c dist/assets/*.js | wc -c

Si react-dom pesa 40 KB gzip y tu app total pesa 400 KB, Redact no reduce tu bundle un 66%: reduce ese bloque. Haz la cuenta sobre el peso del runtime, no sobre el total. Si tu runtime es el 10% del JavaScript, un cambio de runtime mueve poco la aguja; si es el 40%, la conversación cambia.

Cómo probar Redact sin reescribir tu código

La adopción es incremental: Redact no te pide migrar tu arquitectura de estado ni tus rutas, pero sí revisar los puntos donde tu código dependa de comportamientos específicos de React. Un checklist mínimo antes de decidir:

  • Contexto. Los providers de contexto de Redact no propagan valores como los de React. Si usas createContext con actualizaciones dinámicas, esto te va a doler.
  • Portales. Los portales renderizan en su lugar, no en otro nodo del DOM. Modales, tooltips y toasts que dependen de mover el árbol rompen.
  • Lazy. lazy solo resuelve lo que ya es síncrono; no esperes el comportamiento de carga diferida de React.
  • Hidratación. Prueba SSR e hidratación con el flujo real de tu app, no con el ejemplo de la documentación.
  • DevTools. No hay inspección en React DevTools. Tu equipo pierde esa herramienta de depuración.

Monta un entorno con la configuración de Vite o Next.js que ya usas, cambia solo el runtime y corre tu suite de pruebas de integración. Si tus pruebas pasan y tus pantallas críticas se comportan igual, tienes una señal. Si no, ya sabes qué componente te está atando a React.

Qué ganas y qué pierdes con el runtime síncrono

El runtime de Redact es síncrono: no tiene el scheduling concurrente de React. Eso significa que pierdes la capacidad de interrumpir un render para atender una interacción más prioritaria, que es la base de useTransition, useDeferredValue y del renderizado concurrente.

Lo que ganas es previsibilidad y peso. Un runtime síncrono es más fácil de razonar, y la documentación de compatibilidad de Redact lista estas diferencias sin maquillarlas. Si tu aplicación nunca usó concurrencia real —y muchos dashboards internos no la usan—, no estás renunciando a algo que aprovechabas. Si dependes de transiciones para mantener fluida una lista grande, sí lo vas a notar.

Cuándo NO conviene cambiar de runtime

No cambies si alguna de estas frases describe tu proyecto:

  • Tu bundle no es el problema. Si el JavaScript de framework es una fracción menor del total, tu cuello de botella está en imágenes, fuentes o consultas al API. Redact no lo arregla.
  • Dependes del scheduling concurrente. Uso intensivo de transiciones, listas largas con renderización prioritaria o Suspense con datos en streaming: quédate en React.
  • Usas portales y contexto de forma intensiva. Modales globales, temas dinámicos, i18n por contexto: el costo de adaptar todo supera el ahorro de bytes.
  • Tu equipo es pequeño y sin margen. Un runtime en 0.x cambia rápido. Adoptarlo implica seguir issues y probar cada actualización. Si nadie tiene ese tiempo, el riesgo no se justifica.
  • Necesitas React DevTools en el día a día. Perder esa inspección encarece depurar problemas de rendimiento reales.

La regla práctica: cambia de runtime solo si el runtime es una porción grande de tu bundle y tu app no usa las funciones que Redact no implementa. Las dos condiciones juntas, no una.

Si quieres bajar el JavaScript sin cambiar de motor, hay caminos menos riesgosos: divide rutas con import() dinámico, mueve trabajo al servidor con Server Components donde tu stack lo permita y revisa qué dependencias entran completas cuando solo usas una función. Antes de adoptar un runtime en 0.x, mide el peso real de react y react-dom en tu build y documenta qué APIs de React usas. Ese inventario te dirá en una tarde si Redact es una opción o una distracción.

Preguntas frecuentes

¿TanStack Redact reemplaza a React por completo?

No. Reemplaza el runtime que interpreta tus componentes, no la API que escribes. Tus archivos .jsx y tus hooks siguen ahí; lo que cambia es el motor que los ejecuta y algunas garantías de comportamiento.

¿Puedo usar Redact con Next.js?

TanStack publica integraciones estables para Next.js, además de TanStack Start, Vite y Vinext. Aun así, valida el comportamiento de SSR e hidratación en tu flujo real antes de llevarlo a producción.

¿Cuánto reduce realmente mi bundle?

Depende de cuánto pese tu runtime actual. Si React y react-dom son el 40% de tu JavaScript, el ahorro es visible; si son el 8%, el impacto es marginal. Mide con tu build, no con cifras de referencia.

¿Redact sirve para apps que usan Suspense y transiciones?

Con reservas. El runtime es síncrono y no incluye el scheduling concurrente de React, así que las funciones que dependen de él no tienen el mismo comportamiento. Si tu app las usa de forma crítica, no es el camino.

¿Vale la pena probarlo en un proyecto en producción?

Solo en un entorno controlado y con pruebas de integración que cubran contexto, portales, lazy e hidratación. Empieza en una rama aparte, mide el bundle antes y después, y decide con datos de tu propia app.

Compartir