Si llevas un par de años sin tocar React, prepárate: la forma de escribir componentes ha cambiado más en los últimos doce meses que en los cuatro anteriores juntos. La pieza central de ese cambio es el React Compiler, y si todavía estás salpicando tu código de useMemo y useCallback por costumbre, es un buen momento para dejar de hacerlo.
El fin de la memoización manual
Durante años, optimizar una app en React significaba una rutina muy concreta: envolver funciones en useCallback, envolver valores calculados en useMemo, y rezar para no equivocarte en el array de dependencias. Un error ahí y tenías un bug de rendimiento silencioso, o peor, un bucle de renders infinito que tardabas media tarde en cazar.
El React Compiler analiza tu código en build y aplica la memoización automáticamente donde hace falta — gran parte del código de optimización que escribías a mano durante años deja de ser necesario.
El React Compiler, que llevaba tiempo en desarrollo interno en Meta, ya es estable y de uso general. useMemo y useCallback no han desaparecido del lenguaje — siguen ahí para casos concretos — pero ya no son el pan de cada día.
Server Components, ahora la normalidad
Los React Server Components han pasado de ser una idea experimental a ser práctica estándar, en buena parte gracias a que frameworks como Next.js los activan por defecto desde hace varias versiones. La idea de fondo: partes de tu interfaz se renderizan directamente en el servidor, así que ese código nunca llega al navegador del usuario ni pesa en el bundle final de JavaScript.
Para quien viene de las SPA clásicas, esto supone un cambio de mentalidad más que técnico: ya no todo componente "vive" en el cliente por defecto. Hay que decidir, componente a componente, si necesita interactividad en el navegador o si puede quedarse tranquilamente en el servidor.
Renderizado concurrente, sin que se note
La otra pieza que ya ha madurado del todo es el modo concurrente: React puede renderizar de forma asíncrona, priorizando las actualizaciones que de verdad importan para el usuario sobre las que pueden esperar un instante. El resultado práctico es una interfaz que se siente más fluida bajo carga, sin bloqueos perceptibles, aunque por debajo esté haciendo bastante más trabajo del que hacía antes.
Qué significa esto para el día a día
Si estás empezando un proyecto nuevo hoy, la recomendación es sencilla: deja que el Compiler haga su trabajo, no memoices por costumbre, y piensa en Server Components desde el diseño inicial de la app, no como un parche a posteriori. Si mantienes un proyecto existente con mucho useMemo/useCallback esparcido por todas partes, no hace falta salir corriendo a borrarlo todo — pero sí vale la pena revisar si esa optimización manual sigue aportando algo una vez el Compiler entra en juego.
