Por qué es difícil el frontend después de React: estado, efectos, límites y herramientas de IA
React hizo que las interfaces de usuario fueran más fáciles de construir, no de diseñar. Donde reside el estado, los efectos complejos, los límites del sistema y el código generado por IA constituyen el verdadero trabajo en el frontend.
Fuentes: React Isn’t the Hardest Part of Frontend Development
Algunos desarrolladores front-end pueden crear un componente de React en veinte minutos, pero luego pasan las siguientes tres horas intentando averiguar por qué ahora es imposible mantenerlo. La culpa no es de JSX, ni de useState, ni tampoco del propio React. Lo que hace que el trabajo front-end sea difícil son los aspectos relacionados con el framework: saber cómo debe comportarse un producto, decidir dónde se almacenará el estado, coordinar las llamadas asíncronas, delimitar los componentes, lidiar con las peculiaridades del navegador, mantener las interfaces accesibles y rápidas, y dejar código que siga teniendo sentido medio año después.
React facilitó la creación de interfaces. Nunca facilitó el trabajo de ingeniería front-end, y este campo ha pasado demasiado tiempo actuando como si lo hubiera hecho.
Lo que arregló React y lo que dejó sin tocar
Antes de que React tomara el control, la dificultad era de otro tipo. Los desarrolladores editaban el DOM a mano y conectaban los manejadores de eventos uno por uno, y tenían dificultades para mantener la pantalla al día con los datos de la aplicación. A medida que las aplicaciones crecían, rastrear cómo se relacionaban las acciones del usuario, los datos y los elementos renderizados se volvía cada vez más complicado.
React ofreció un modelo mental útil: la interfaz de usuario es una función del estado. En lugar de instruir al navegador sobre cada cambio en el DOM, se describe cómo se verá la interfaz para un estado determinado. Los componentes establecen límites, las props proporcionan entradas explícitas, el estado representa los datos que cambian con el tiempo, y el renderizado declarativo elimina gran parte de la complejidad accidental. Eso fue un verdadero avance.
Aun así, un framework solo resuelve lo para lo que fue creado. React no tiene opinión sobre si una aplicación necesita cinco elementos de estado global o cincuenta. No indicará cuándo un componente está haciendo demasiado, si el diseño de la API es sensato, si los indicadores de carga se encuentran en los lugares adecuados, o si un flujo de pago tiene sentido para el comprador. Tampoco puede decidir qué debe hacer el producto cuando la conexión se interrumpe a mitad de la solicitud. Todo eso también son problemas del frontend.
Una función ordinaria frente a la realidad
Tomemos un panel de control sencillo. Un usuario lo abre, la aplicación obtiene datos, él cambia un filtro, los resultados se actualizan, elige un elemento, se abre un modal, edita y guarda los cambios, el servidor responde y el panel de control se actualiza. Nada de eso suena difícil.
Ahora añada lo que realmente sucede. La primera solicitud falla. El filtro cambia mientras una solicitud anterior aún está en trámite, y la respuesta anterior llega después de la más reciente. El modal se abre a partir de un enlace profundo. La página se actualiza mientras se está editando. Hay dos pestañas abiertas. La sesión expira. La API devuelve datos parciales. El servidor acepta una mutación, pero el cliente nunca ve la respuesta, y el usuario hace clic en guardar dos veces. La lista tiene 10,000 filas, la conexión es lenta y se realiza desde un dispositivo móvil, la interfaz debe funcionar con teclado, y el mensaje de error debe indicar qué pueden hacer a continuación.
En ese punto, el código de React es la parte menos interesante. Todo esto se puede construir con React, y todo esto también se puede construir mal. Muchos desarrolladores pasan por alto esa diferencia.
La tarea consiste en gestionar la complejidad
El trabajo de un desarrollador frontend no consiste principalmente en escribir componentes. Se trata de absorber la complejidad para que el usuario vea algo simple, lo cual es mucho más difícil. Un componente bien elaborado puede tener cincuenta líneas de código, pero llegar a cincuenta en lugar de quinientas requiere una serie de decisiones:
- De dónde provienen los datos, quién es el responsable de ellos, cuánto tiempo permanecen y quién puede modificarlos
- Qué sucede cuando una solicitud falla
- Si el estado debe mantenerse tras una navegación o un refresco
- Si pertenece a la URL, al estado local del componente o a la caché del servidor
- Si dos componentes deben compartir los datos directamente o calcular valores similares por separado
React no responde a ninguna de estas preguntas. El desarrollador sí lo hace, y las respuestas se acumulan. Una decisión deficiente rara vez se queda dentro de un solo componente; se convierte en un patrón que otros desarrolladores copian, y pronto la aplicación tiene una arquitectura consistente que nadie eligió. Así es como los repositorios de código frontend se vuelven problemáticos: las decisiones se acumulan, y la complejidad de React tiene poco que ver con ello.
El estado como problema de modelado
Una forma rápida de detectar un diseño frontend inmaduro es observar su estado. Un uso excesivo de useState no es incorrecto en sí mismo. El problema radica en tratar el estado como un lugar donde guardar valores y no como algo que se debe modelar. El desarrollador ve un valor que cambia y recurre al hook correspondiente.
const [value, setValue] = useState(...)
Parece estar listo, pero cómo almacenar el valor no es la verdadera pregunta. Lo importante es si el valor debería existir en absoluto. Miren este trío:
const [firstName, setFirstName] = useState("");
const [lastName, setLastName] = useState("");
const [fullName, setFullName] = useState("");
Tres componentes del estado albergan ahora información que podría obtenerse a partir de dos. React no es el culpable aquí; el modelo mental sí lo es.
Lo mismo ocurre a gran escala. Los equipos guardan respuestas de API, copias filtradas de esas respuestas, indicadores de carga, conteos derivados, registros seleccionados, indicadores de modales y versiones duplicadas de una misma entidad en varios lugares. Con el tiempo, nadie puede determinar cuál copia es la autoritativa, y surgen errores. Un componente modifica una copia mientras otro lee otra diferente. Un efecto de sincronización intenta alinearlas, y otro efecto reacciona al primero. De repente, el navegador contiene un pequeño sistema distribuido. React no construyó esa arquitectura; quienes escriben el código sí lo hicieron.
Los efectos exponen el diseño
Si hay una característica de React que recibe más críticas que las demás, es useEffect, y con frecuencia esas críticas son justificadas. Pero generalmente es en los efectos donde aparecen los problemas arquitectónicos, no donde comienzan.
Imagínese un componente con varios efectos: uno para obtener datos, otro para sincronizar el estado, otro para reaccionar a cambios en propiedades, otro para escribir en el almacenamiento local, otro para enviar datos a análisis y otro para restablecer algo cuando cambia una condición. Cada uno parece razonable por separado. Juntos forman un grafo de dependencias difícil de seguir. El desarrollador agrega dependencias hasta que el analizador deja de emitir advertencias, o elimina algunas porque el efecto se ejecuta con demasiada frecuencia, o añade un ref booleano para evitar ejecuciones duplicadas. Al final, el componente funciona para el escenario que se está probando, pero nadie está del todo seguro de por qué.
Eso no es un defecto de React. Se trata de una falta de claridad en la responsabilidad y de efectos secundarios entrelazados, y React simplemente les proporciona un lugar donde existir.
El navegador es un nodo en un sistema más grande
El alcance del trabajo frontend sigue ampliándose. Una aplicación moderna se comunica con APIs y bases de datos, sistemas de autenticación y herramientas de análisis, además de flags de funcionalidades, proveedores de pago y otros servicios de terceros. También se incluyen funciones de edge, componentes de servidor, tareas en segundo plano y, cada vez más, servicios respaldados por inteligencia artificial. El navegador es solo uno de los participantes en un sistema mucho más amplio, por lo que un desarrollador frontend debe comprender no solo el proceso de renderizado, sino también lo que ocurre antes y después de que una solicitud abandone la página.
Eso no significa que todos tengan que convertirse en especialistas en backend. Significa que la antigua división entre frontend y backend se está volviendo menos útil. Quien no conozca HTTP eventualmente tendrá dificultades con el caché. Quien no esté familiarizado con las bases de datos tendrá problemas para comprender la consistencia, y quien no entienda la autenticación tropezará con el comportamiento de las sesiones. Las condiciones de carrera y las reintentos confunden a los desarrolladores sin conocimientos en sistemas distribuidos, y aquellos que no entienden a los usuarios crearán interfaces elegantes de las que nadie disfrutará. El framework es una sola capa.
La IA cambia la economía, no la parte difícil
Los asistentes de programación basados en IA han cambiado el costo del trabajo de frontend. La creación de componentes, formularios, la conversión de diseños a JSX, los hooks y las pruebas se ha vuelto más económica. Eso podría sonar como una amenaza, pero es mejor verlo como una prueba de dónde realmente residía el valor. Si tu principal aporte es escribir JSX rápidamente, la IA representa un problema. Pero si se trata de comprender los sistemas, la arquitectura, el comportamiento del producto, las trade-offs y a los usuarios, la IA modifica tu flujo de trabajo, mantiene la parte más difícil intacta y, probablemente, aumenta su importancia.
Un asistente puede redactar tres versiones plausibles de una función en cuestión de segundos. Elegir entre ellas es una decisión de arquitectura y no de sintaxis. Puede crear una configuración de gestión de estados, pero, ¿debería ese estado ser global? Puede escribir una actualización optimista, pero, ¿debería la aplicación comportarse realmente de forma optimista? Puede agregar un caché, pero, ¿cuál es la estrategia de invalidación? Puede escribir un efecto, pero, ¿debería ese efecto existir? Cuanto más rápido aparece el código, mayor es la necesidad de juicio, y eso probablemente definirá el trabajo en frontend en los próximos años.
Los desarrolladores frontend competentes tienden a pensar menos en React y más en los límites de su funcionalidad. Se preguntan dónde reside la responsabilidad y se dan cuenta cuando un componente se convierte en una pequeña aplicación. Cuestionan la duplicación de estado, planifican escenarios de fallo antes de considerar el camino óptimo, saben qué es lo que realmente garantiza la API y prestan atención al comportamiento inesperado de los usuarios. Son capaces de determinar cuándo una abstracción es útil y cuándo solo oculta la complejidad. Entienden cómo funciona el navegador, ajustan el rendimiento sin optimizar todo de forma prematura y, sobre todo, pueden explicar por qué el sistema funciona de la manera en que lo hace. Esa es una habilidad mucho más difícil de automatizar y dura más tiempo que conocer la API más reciente de React.
El conocimiento de los frameworks caduca
Los desarrolladores no hablan lo suficiente de esto: el conocimiento de los frameworks tiene una vida útil limitada. La API de React que se aprendió hace cinco años ya no es la misma de hoy. Las mejores prácticas cambian, las bibliotecas desaparecen, las herramientas de compilación evolucionan, las estrategias de renderizado se actualizan, las capacidades del servidor crecen y surgen nuevos frameworks. La sintaxis varía, pero los problemas de ingeniería subyacentes permanecen sorprendentemente estables:
- Modelado del estado y transmisión de datos a través del sistema
- Manejo de fallos y gestión de tareas asíncronas
- Evitación de acoplamientos innecesarios
- Hacer que el sistema sea observable y la interfaz accesible
- Mantener la complejidad bajo control
Estos problemas sobrevivieron a jQuery, Angular y Backbone, así como al primer ecosistema de React. Sobrevivirán a todo lo que venga después. Por lo tanto, aprender desarrollo frontend únicamente a través de frameworks es un plan frágil. Aprende el framework, pero no lo confundas con la disciplina necesaria.
Es posible que algún día React deje de ser el centro de atención. Algo podría reemplazarlo, varias alternativas podrían coexistir, o podría seguir siendo dominante mucho más tiempo de lo esperado. Eso no importa demasiado. Los desarrolladores cuya identidad se basa en las APIs de React tendrán que reconstruirlas, mientras que aquellos que comprenden cómo funcionan realmente las interfaces se adaptarán.
React es la herramienta, no el oficio
El desarrollo frontend nunca estuvo fundamentalmente relacionado con React. React es una herramienta muy buena para crear aplicaciones frontend, y sigue siendo una herramienta. Lo difícil es decidir qué expresar: cómo interactúan las partes, qué ocurre cuando algo falla, dónde reside el estado, qué se ejecuta en el navegador y qué en el servidor, cómo crece el sistema junto con el producto, y cómo ocultar todo eso a la persona que lo utiliza. Ese es el trabajo, y JSX es simplemente la forma en que se escribe parte de él.
A medida que las herramientas mejoran en la generación de código, su valor disminuye. Eso no pone fin al desarrollo de software, aunque sí cambia en qué deben concentrarse los desarrolladores. Quien puede generar un componente rápidamente es útil, pero quien sabe determinar si ese componente debería existir lo es aún más. Lo mismo ocurre con las integraciones de API: generar una es útil, pero detectar que el contrato en sí es incorrecto tiene aún más valor. Un desarrollador que puede pedirle a la IA que refactore un código base tiene utilidad, y aquel que puede determinar si el refactor propuesto mejora el sistema tiene aún más valor.
Por lo tanto, nadie debería preocuparse porque React se haya vuelto más sencillo. Ese es el objetivo, ya que la finalidad de un framework es reducir el trabajo innecesario, y un desarrollador experimentado utiliza el tiempo ahorrado en resolver problemas realmente importantes.
Leer más
- Construyendo un agente ReAct en LangChain: Ejecutores, pizarras y sus limitaciones — Crea un agente ReAct que utiliza herramientas, observa cómo el agente y AgentExecutor dividen el trabajo, y entiende por qué LangGraph maneja mejor el flujo de control, los ciclos y el estado.
- Cuando la memorización de React tiene efectos negativos: por qué menos renderizaciones ralentizaron la aplicación — Cómo memo, useMemo y useCallback generaron costos adicionales y errores en una página grande de React, y por qué mover el estado y analizar todas las interacciones solucionó el problema.