No todo necesita React: HTMX y el costo oculto de la complejidad

Hay un momento en casi todos los proyectos web en el que parás, abrís el package.json y te preguntás cómo llegaste hasta ahí. Querías hacer algo simple: un formulario que guarde datos y una pantalla que los liste. Y terminaste con un framework, un bundler, un manejador de estado, una librería para traer datos del servidor, tipos de TypeScript por todos lados y una suite de tests para asegurarte de que todo ese andamiaje no se derrumbe. El CRUD tiene tres pantallas. El tooling tiene veinte dependencias.

A eso los que escriben software le dicen complejidad accidental: la que no nace del problema que estás resolviendo, sino de las herramientas que elegiste para resolverlo. Y hace un tiempo que vengo pensando que en el frontend nos acostumbramos a pagarla sin darnos cuenta. HTMX es, para mí, la excusa perfecta para replantearlo.

Seamos justos con React

Antes de tirarle piedras, hay que reconocer qué vino a resolver. React (y las SPA en general) apareció porque había un problema real: interfaces genuinamente complejas, con mucho estado que cambia en el cliente, que con recargas de página completas se sentían lentas y torpes. Pensá en un Gmail, un editor, un tablero que se actualiza en vivo. Ahí tener toda la lógica de la interfaz corriendo en el navegador, manteniendo su propio estado, tiene todo el sentido del mundo.

El problema no es React. El problema es que agarramos esa herramienta pensada para el 5% de las aplicaciones y la empezamos a usar para el 95% restante: blogs, sitios de contenido, paneles de administración, CRUDs internos. Aplicaciones que, seamos honestos, nunca necesitaron un runtime entero en el navegador.

El costo que nadie mira: la hidratación

Acá está la parte que más me hizo ruido cuando la entendí bien. En una SPA moderna con renderizado en el servidor, pasa algo medio absurdo: el servidor genera el HTML, se lo manda al navegador, el usuario ve la página… pero todavía no puede tocar nada. Porque después el navegador tiene que bajar el bundle de JavaScript, parsearlo, ejecutarlo y volver a construir en memoria todo el árbol de componentes para “engancharse” al HTML que ya estaba ahí. Ese proceso se llama hidratación, y es, básicamente, hacer el trabajo dos veces.

El resultado es esa sensación rara de una página que aparece rápido pero que si le hacés clic a un botón durante el primer segundo, no responde. En una conexión buena ni lo notás. En un celular de gama media, con señal regular, la diferencia entre “usable” y “todavía cargando” se estira feo. Y ese costo lo pagás en cada visita, aunque tu aplicación no lo necesite para nada.

Qué propone HTMX

La idea de HTMX es casi provocadora de lo simple que es: ¿y si el servidor sigue haciendo lo que siempre supo hacer —generar HTML— y el navegador vuelve a ser lo que era, un visor de ese HTML?

En lugar de mandar datos crudos en JSON para que el cliente los transforme en interfaz, el servidor manda directamente el pedacito de HTML ya armado. Vos, en el HTML, ponés unos atributos: “cuando hagan clic acá, pedile esto al servidor y reemplazá este cachito de la página con lo que devuelva”. Nada de estado duplicado, nada de virtual DOM, nada de sincronizar el modelo del cliente con el del servidor. La fuente de verdad vuelve a estar en un solo lugar.

Son unos 14 KB de JavaScript, sin build obligatorio, y de repente el 80% de la interactividad que resolvías con toneladas de tooling se resuelve con atributos en el HTML. A esto se lo empezó a llamar hypermedia driven application: la simplicidad de una web tradicional de varias páginas, pero con la fluidez que asociábamos a las SPA.

Y ahora la parte honesta

Sería muy fácil cerrar acá con un “tirá React a la basura”, pero eso sería mentirte. HTMX no reemplaza a React; es una alternativa para las aplicaciones que nunca necesitaron a React en primer lugar. Son cosas distintas.

Hay un montón de casos donde React (o similar) sigue siendo la respuesta correcta, y no por moda: editores colaborativos tipo Google Docs, un Figma, una app que tiene que funcionar offline, cualquier interfaz con estado local que cambia muchísimas veces por segundo y que no puede darse el lujo de ir y volver al servidor en cada interacción. Ahí la latencia de red te mata, y necesitás sí o sí un cerebro completo corriendo en el navegador. Meter HTMX ahí sería tan equivocado como meter React en un blog.

Mi criterio, después de todo esto

Lo que cambió para mí no es tanto “HTMX bueno, React malo”, sino la pregunta con la que arranco un proyecto. Antes era: ¿qué framework uso?, y la respuesta por defecto era React porque era lo que todos usaban. Ahora la pregunta es: ¿cuánta complejidad justifica realmente esto que estoy por construir?

Tengo una especie de presupuesto de complejidad en la cabeza. Arranco por lo más simple que pueda resolver el problema —server-rendered HTML, y HTMX cuando necesito interactividad puntual— y solo subo de nivel cuando choco contra una pared que puedo nombrar con precisión. “Necesito estado local complejo que no puede ir y volver al servidor” es una razón. “Es lo que se usa” no lo es.

Nueve de cada diez veces, esa pared nunca aparece. Y la aplicación termina siendo más rápida, con menos código, más fácil de mantener y sin veinte dependencias que actualizar cada semana. La web no se volvió complicada porque los problemas se volvieron más difíciles. Se volvió complicada porque nos olvidamos de que la opción simple seguía estando ahí.