Algo molesto con React
La evolución de React, de una biblioteca sencilla de UI del lado del cliente a un ecosistema dominado por hooks, componentes de servidor y frameworks como Next.js, está dejando a muchos desarrolladores frustrados por el aumento de la complejidad y modelos mentales opacos. Los comentaristas señalan puntos de dolor como el uso excesivo de `useEffect`, la depreciación de Create React App y el impulso hacia configuraciones basadas en Node y muy dependientes del servidor, argumentando que esto hace que las apps web modernas sean más lentas, más difíciles de razonar y menos agradables de construir. Algunos siguen elogiando el ecosistema y la flexibilidad de React, pero muchos se están inclinando hacia alternativas como Svelte, Solid, Vue, Preact o incluso los estándares web puros para frontends más simples y deterministas.
React del lado del cliente vs Componentes de servidor / Next.js
- Muchos sienten que React se ha “dividido en dos”: el React clásico del lado del cliente frente al nuevo mundo de componentes de servidor/Next.js.
- Varias personas extrañan poder publicar una app sencilla de React mediante CDN sin Node ni un framework completo.
- Algunos ven los Componentes de servidor y SSR como una extralimitación o una ampliación de alcance; otros los ven como el futuro oficial, especialmente a través de Next.js.
- Algunos sospechan que los componentes de servidor sirven sobre todo a los intereses de los proveedores de hosting (más cómputo en servidor, bloqueo con el proveedor) más que a beneficios claros a nivel de app.
Debate sobre Hooks y useEffect
- Los Hooks dividen opiniones: algunos los llaman una de las mejores ideas en frameworks de componentes; otros los ven como un nuevo paradigma confuso, distinto tanto de FP como de OOP.
- Hay quejas repetidas de que
useEffectimpulsa la complejidad, las condiciones de carrera y el “spaghetti” cuando se usa en exceso o para carga de datos y orquestación de estado. - Otros argumentan que
useEffectdebería ser raro, usado principalmente para sistemas externos/APIs del DOM, con los datos gestionados por bibliotecas (React Query, SWR, etc.). - Incluso hay desacuerdo sobre lo que React enseña realmente: la documentación muestra
useEffectpara hacer fetch y a la vez advierte que no lo hagas.
Complejidad, DX y alternativas
- Varios comentaristas dicen que las apps modernas de React son más difíciles de razonar que stacks anteriores (Backbone, jQuery simple, PHP, el primer Facebook).
- Otros responden que las interfaces complejas siempre serán complejas, y que React sigue siendo un buen punto intermedio.
- Alternativas elogiadas: Solid, Svelte, Vue, HTMX, Preact, Lit, Web Components nativos, a veces con Vite; muchos dicen que se sienten más cercanas al “React antiguo” o a modelos mentales más simples.
Gestión de estado y arquitectura
- Críticas de que React fomenta la colocación conjunta de la lógica de negocio, la obtención de datos y la vista en componentes gigantes.
- Algunos abogan por una separación estricta mediante Redux/MobX o “servicios” externos, usando componentes como puro
state → UI. - Otros señalan que Redux/MobX también pueden abusarse mucho; los equipos grandes y la presión por tiempo suelen provocar la degradación de la arquitectura independientemente del framework.
Cambios en la tooling y comunicación
- Create React App es percibido ampliamente como efectivamente deprecado, sin un reemplazo claro en la historia oficial.
- Next.js se ve como el camino bendecido de facto, lo que molesta a quienes no construyen apps basadas en Node.
- Vite + bibliotecas más ligeras (Preact, etc.) se citan con frecuencia como un “CRA” moderno y práctico no oficial.
- Varios critican la comunicación de React por inconsistente u opaca, lo que contribuye a la confusión y la frustración.