- En el desarrollo web moderno, la falsa dicotomía entre HTML y los grandes frameworks de JavaScript está empujando a los desarrolladores hacia una complejidad innecesaria
- HTMX maneja peticiones AJAX, actualizaciones parciales y transiciones animadas solo con atributos HTML, ofreciendo una forma de reflejar en pantalla el HTML que devuelve el servidor tal cual
- Puede adoptarse de forma gradual sin modificar en gran medida la base de código existente, reduciendo la complejidad del frontend y mejorando la productividad y mantenibilidad
- En comparación con una SPA basada en React, en producción ya se han visto mejoras importantes en cantidad de código, dependencias, tiempo de build y velocidad de carga
- Más que elegir frameworks excesivos, un enfoque simple basado en hipermedia resulta más favorable a largo plazo para la productividad y el mantenimiento
Planteamiento del problema: la falsa elección del desarrollo web
- En las discusiones sobre desarrollo web, solo se repiten opciones extremas: usar solo HTML o usar un gran framework como React
- El HTML puro tiene funciones base potentes como enlaces, formularios y
dialog, pero tiene limitaciones en la actualización parcial y la respuesta inmediata
- Al elegir React, Vue o Angular, llegan cientos de dependencias, builds lentos y discusiones complejas sobre manejo de estado
- Incluso para apps simples centradas en CRUD, dashboards y formularios, se termina aplicando un ecosistema de herramientas excesivo
Concepto central de HTMX
- HTMX es una herramienta que realiza comunicación asíncrona con el servidor agregando atributos especiales a elementos HTML
- Por ejemplo, con los atributos
hx-get y hx-post se envían peticiones y la respuesta se inserta en un área específica del DOM
- Amplía el HTML para que todos los elementos HTML puedan convertirse en emisores de peticiones HTTP
- El servidor devuelve fragmentos de HTML tal cual, no JSON, y ese HTML devuelto se reemplaza o inserta automáticamente en la ubicación indicada
- Define el comportamiento solo con declaraciones en atributos HTML, sin escribir JavaScript directamente
- El tamaño de la librería es de aproximadamente 14kb (gzip), por lo que es muy ligera
- Puede aplicarse directamente a documentos HTML existentes sin herramientas de build ni configuración adicional de frameworks
- Encaja bien con el enfoque tradicional de desarrollo web centrado en renderizado del lado del servidor
Funciones principales
- Manejo de peticiones AJAX: realiza peticiones GET y POST solo con atributos HTML
- Actualización del DOM: refleja automáticamente en el elemento indicado el HTML devuelto por el servidor
- Manejo de eventos: conecta llamadas al servidor con eventos del usuario, como clics o entradas
- Gestión del historial: se integra con las acciones de atrás y adelante del navegador
Casos reales y métricas
- Contexte migró un SaaS basado en React a Django + HTMX
- Reducción del 67% en líneas totales de código (21,500 → 7,200)
- Reducción del 96% en dependencias de JavaScript (255 → 9)
- Reducción del 88% en tiempo de build (40 segundos → 5 segundos)
- Mejora del 50~60% en velocidad de carga de páginas
- Se eliminó dos tercios de la base de código y la app quedó mejor
- Sin separar frontend y backend, todos los desarrolladores pudieron trabajar como full stack
Respuestas a objeciones comunes
- "¿No hace falta un manejo complejo del estado del cliente?"
- En la práctica, la mayoría de los casos son formularios, listas y elementos que aparecen según el clic, y HTMX es suficiente para manejarlos
- Herramientas de colaboración en tiempo real como Google Docs sí son una excepción, pero en la mayoría de los casos se está sobreestimando la complejidad de las apps CRUD
- "¿Y las ventajas del ecosistema de React?"
- Un ecosistema enorme también implica GB de
node_modules, opciones interminables y debates sobre manejo de estado
- El ecosistema de HTMX se reduce a un solo lenguaje del lado del servidor, el que elijas
- "¿La SPA no se siente más rápida?"
- Al inicio, hay que pasar por descarga, parseo, ejecución e hidratación de grandes volúmenes de JavaScript
- HTMX carga rápido desde el principio y luego mantiene una buena respuesta al reemplazar solo las partes que cambiaron
- "¿Y si de verdad necesito una función específica de React?"
- En algunos casos React puede ser la opción adecuada
- Aun así, en la práctica muchas veces se elige por costumbre una herramienta que solo hace falta para una pequeña parte del problema total
- ¿Por qué elegir HTMX?
- Los equipos no fracasan por elegir el framework equivocado, sino por elegir demasiado framework
- HTMX apuesta por la simplicidad, y a largo plazo esa simplicidad ofrece ventajas en mantenibilidad y productividad
Cuándo HTMX no es adecuado
- Herramientas de edición colaborativa en tiempo real (Google Docs, Figma)
- Aplicaciones que requieren grandes cálculos del lado del cliente (editores de video, herramientas CAD)
- Arquitecturas offline-first (aunque también se pueden combinar varios enfoques)
- Casos que realmente requieren un estado de UI complejo
- Pero, ¿de verdad estás construyendo algo así?
- ¿O más bien estás haciendo otro dashboard, panel de administración, sitio de comercio electrónico, blog o app SaaS compuesto solo de formularios, tablas y listas?
- Para ese tipo de cosas, HTMX es realmente sorprendentemente bueno. Al punto de pensar: "¿Por qué lo hice tan complicado?" o "Dios mío, desperdicié demasiado tiempo en esto"
Así que inténtalo una vez
- Ya usaste React, ya probaste Vue, y probablemente también probaste Angular y te arrepentiste, ¿no?
- Seguro que también ya tocaste al menos una vez el meta-framework de moda esta semana en Hacker News
- Simplemente prueba HTMX хотя sea una vez
- Invierte un día del fin de semana
- Elige un proyecto personal
- O una herramienta interna a la que nadie le presta demasiada atención
- O saca algo que has estado posponiendo para rehacer algún día
- Agrega una etiqueta
<script> y escribe un atributo hx-get, luego comprueba por ti mismo cómo funciona
- En el peor de los casos, solo pierdes un día del fin de semana
- Pero probablemente no te va a disgustar
- De hecho, terminarás preguntándote por qué el desarrollo web tuvo que volverse tan complicado
8 comentarios
El año pasado hice una presentación como esta. Aunque casi nadie la escuchó ^^
https://www.slideshare.net/slideshow/htmx-2024/274315966
A nivel de PoC también hice algo como esto
https://github.com/iolo/hx
Pero nadie usa htmx jaja
Es una pena que, una vez que nos acostumbramos a la situación actual y se ha consolidado un ecosistema tan grande, parezca que se ha estancado y que ya no haya impulso hacia la innovación.
Las diapositivas están muy entretenidas. Qué lástima que no pude ver la presentación jajaja
Recuerdo haber escuchado una charla relacionada en PyCon, y también se me quedó grabado que el ponente dijo que aún no había podido usarlo en un entorno laboral real.
¿Rust, por favor, podrían probarlo aunque sea una vez?
He probado usar Alpine.js, pero en la mayoría de los casos sí necesitaba manejo de estado...
Recuerdo que, a menos que estuviera diseñado desde el inicio para que el backend manejara el estado, resolver estados por etapas, estados condicionales y cosas así era bastante engorroso.
Coincido con todo lo que dicen, pero nomás no me dan ganas de usar htmx :(
Opiniones de Hacker News
Soy el creador de htmx. Agradezco la atención que trae un artículo exagerado, pero este tipo de hype no me gusta mucho
Hay muchas formas de crear apps web, y cada una tiene ventajas y desventajas. En este artículo resumí las fortalezas y debilidades de htmx
También recomiendo probar Unpoly, otra excelente librería orientada a hypermedia
(Actualización) Volví a leer el artículo y estaba mejor de lo que pensé. Aun así, me gustaría que htmx se tratara con un tono más mesurado
Actualizar campos con dropdowns, crear modales, cajas de búsqueda con autocompletado: todo es sencillo
Aun así, la complejidad de un frontend RIA está en cómo actualizas el frontend cuando cambian los datos.
Hace falta cierto ajuste en el backend, y sería aún mejor tener una estructura que pueda manejar varias actualizaciones parciales al mismo tiempo
Ahora mismo tengo un proyecto personal con Rails + Stimulus, y Stimulus incluso se siente excesivo. Me pregunto cuándo conviene elegir Inertia o Stimulus
Es un plugin de Alpine.js que agrega funciones AJAX básicas a enlaces y formularios
Ya me cansé de los artículos que aseguran ser mejores que React con un ejemplo de “Hello World”
En ejemplos simples todo funciona bien. Pero en la práctica, la mayoría de los casos tienen un backend con muchas dependencias y una UI compleja
El demo básico está bien, pero hay que mostrar cómo se puede escalar al agregar funciones más complejas
Quiero saber dónde se agrega JS, si hace falta un build step y qué tanto te ata al paradigma de htmx
No es que sea mejor que React, simplemente es otro enfoque
El paradigma de reemplazar partes del DOM es muy simple e intuitivo
Ejemplo: effect-ts es potente, pero incluso una salida simple se vuelve complicada
En nuestra startup adoptamos HTMX, pero al final estamos migrando a React
HTMX tiene una alta complejidad en el manejo de respuestas, y cada endpoint tiene que devolver varios fragmentos de HTML
Faltan documentación y casos de uso, y tampoco hay best practices a gran escala.
React es maduro y además se lleva bien con la programación asistida por IA. HTMX encaja en proyectos simples, pero más allá de eso se complica
Cada endpoint cumple una sola función y, con Optimistic UI, la respuesta es inmediata
El manejo de errores se mantiene simple, y
hx-swap-oobse usa al mínimoLa clave al elegir tecnología es minimizar los trade-offs
Por eso yo me centro en la validación del backend, y dejo que el frontend solo muestre el resultado
Yo no quiero SSR. El backend solo debería ofrecer una API JSON, y el frontend consumirla
Creo que SSR está sobrevendido. Parece más bien una estrategia para impulsar la venta de servicios en la nube
El ejemplo Demo 3 Live Search tiene un serio problema de scroll jank.
Parece que los resultados se insertan directamente en el documento y eso obliga a recalcular el layout constantemente
React está bastante bien. Incluso en proyectos simples, no hay razón para aprender otro paradigma a la fuerza
En cambio, HTMX te toma 15 minutos para entenderlo y te puede servir por 10 años
Históricamente, los paradigmas livianos son los que ganan el mercado. React mismo alguna vez fue eso
Yo no me enamoré de HTMX, sino de Alpine.js
Me hizo clic la idea de potenciar (enhance) HTML renderizado en servidor
Dropdowns, show/hide y demás son intuitivos, y no hace falta un build step
Es intuitivo y fácil de mantener incluso en proyectos grandes
Si metes JS inline en HTML, el mantenimiento se complica y el manejo de estado se vuelve implícito
Siento que Hotwire o Stimulus funcionan mucho mejor a escala organizacional
Si usas HTMX en apps grandes, me pregunto por la carga del servidor y el costo
Como el HTML se renderiza en el servidor, parece que habría más trabajo que con JSON
A veces incluso es más eficiente que serializar JSON, y en el cliente también existe el costo de deserialización
Si usas HTMX junto con herramientas como Alpine.js, incluso estados complejos se pueden manejar fácilmente
No sirve para todos los casos, pero en muchos funciona muy bien
El evangelismo de frameworks es la peor cultura del ecosistema web
Si una solución es buena, al final será adoptada. No hace falta actuar como evangelista
También es exagerado lo de los ataques a npm. htmx igual puede terminar usando npm
En el mundo hay muchas soluciones malas que se adoptaron por marketing y notoriedad
Si quieres defender la verdadera artesanía, hay que resistir esos sesgos
HTMX parece una mezcla de las desventajas de ambos mundos
SSR es cohesivo y CSR tiene una estructura separada; HTMX mezcla ambas cosas y genera acoplamiento implícito
Si quieres mostrar los mismos datos en otro formato, me pregunto si en el backend hay que crear dos endpoints
En la mayoría de las apps, el estado del backend basta, y fuera de mejorar la UX no hay tanto beneficio
Si el servidor arma la página completa, los datos ya están ahí dentro