Por qué me decidí por Alpine.js y me distancié de HTMX
Hola a todos. Hoy, como desarrollador Django enfocado principalmente en el backend, me gustaría hablar sobre los dos protagonistas que lideran la tendencia de 'usar menos JavaScript' en el ecosistema frontend reciente: Alpine.js y HTMX.
Para aquellos como yo, familiarizados con Django y Python, estas herramientas son verdaderamente un regalo. Nos permiten crear sitios web modernos y bastante decentes sin la complejidad de configurar React o Vue. Sin embargo, estos dos amigos tienen propósitos y características muy diferentes. HTMX se especializa en la comunicación con el servidor, mientras que Alpine.js se especializa en la interacción de la interfaz de usuario dentro del navegador.
Para ir al grano, me he convertido en un gran admirador de Alpine.js y me he distanciado un poco de HTMX. Compartiré las razones sin rodeos.

1. Conocimientos previos: HTMX vs Alpine.js de un vistazo
Antes de entrar en materia, he preparado una tabla comparativa sencilla para aquellos que no estén familiarizados con estos dos conceptos.
| Categoría | HTMX | Alpine.js |
|---|---|---|
| Objetivo principal | Comunicación con el servidor (reemplazo de HTML tras solicitud AJAX) | Gestión del estado del cliente (interacción de la UI) |
| Filosofía | Extensión de HTML (centrado en el servidor) | Versión ligera de Vue/React (centrado en el navegador) |
| Formato de datos | Fragmentos HTML (Snippet) | Datos JSON |
| Puntos fuertes | Scroll infinito, búsqueda en tiempo real (enfoque SSR) | Modales, desplegables, cambio de pestañas (enfoque CSR) |
2. Cuatro razones por las que empecé a evitar HTMX
A primera vista, HTMX parece muy conveniente. Sin embargo, a medida que lo aplicaba más profundamente en mis proyectos, surgieron puntos de conflicto con mi estilo de desarrollo.
① "¿Es realmente necesario generar fragmentos HTML en el servidor?" (El dilema del mantenimiento)
Para usar HTMX, el servidor (Django) debe devolver fragmentos HTML en lugar de JSON. Esto no encajaba del todo con mi forma de pensar. * Mi perspectiva: "¿No es más clara la división de roles si el servidor solo proporciona los datos de forma limpia y el cliente se encarga del renderizado?" * La postura de HTMX: "Recibir JSON y luego renderizarlo es un desperdicio. Que el servidor entregue el resultado final es la única fuente de verdad (SSOT)."
Cuando tenía que incluir lógica condicional como if request.htmx: dentro de las plantillas de Django, no podía evitar sentir que la lógica de la vista (View) se fragmentaba y se volvía desordenada.
② ¿No es ya bastante sencilla la lógica AJAX?
Los atributos hx-get y hx-target de HTMX son un excelente 'azúcar sintáctico'. Sin embargo, para alguien que ya ha implementado AJAX con Vanilla JS o con sus propias funciones de utilidad, no son esenciales.
La fetch API de los navegadores modernos es realmente potente. Con solo una línea de fetch dentro de x-init de Alpine.js, se puede obtener un código lo suficientemente declarativo y limpio, por lo que sentí menos la necesidad de seguir las reglas de otra biblioteca.
③ La ruptura crítica de la "Locality of Behavior (LoB)"
Me encanta Alpine.js. Me gusta porque puedo ver inmediatamente qué hace el código en el mismo lugar. Pero HTMX es diferente.
* Alpine.js: El comportamiento se define en el HTML y el resultado ocurre instantáneamente en la memoria del navegador.
* HTMX: El comportamiento se define en el HTML, pero para ver el resultado (el fragmento HTML), tengo que revisar el código del servidor (views.py).
Sentí que esta interrupción del contexto era muy ineficiente. La molestia de tener que abrir constantemente archivos de backend mientras leía el código fue una de las razones decisivas por las que empecé a evitar htmx.
④ La incomodidad de la micro-latencia
HTMX asume que cada interacción implica un viaje de ida y vuelta a la red.
Por muy rápido que sea el servidor, no puede igualar la velocidad de reacción instantánea de Alpine.js dentro del navegador. Esa mínima latencia de 0.1 a 0.2 segundos que se siente al hacer clic era un factor bastante molesto para mí en términos de experiencia de usuario.
Para terminar: ¿Cuál es su opinión?
En resumen, prefiero una arquitectura donde los datos fluyen a través de una API (JSON) y la UI reacciona instantáneamente dentro del navegador. Por eso, la combinación de Alpine.js y DRF (Django REST Framework) es mi favorita.
Lo interesante es que, al revisar comunidades como Reddit recientemente, encontré muchas opiniones opuestas a la mía. Muchos desarrolladores encuentran Alpine.js complejo y están volviendo a HTMX o incluso a combinaciones de jQuery + HTMX. En cualquier caso, parece que la popularidad de HTMX es abrumadora en este momento.
Por supuesto, HTMX es una herramienta excelente. Simplemente no se ajustaba a mi estilo de desarrollo y a mi enfoque de diseño de sistemas. Creo que "no hay una respuesta única, solo la que mejor se adapta a uno mismo".
¿Y ustedes qué opinan? ¿Están satisfechos con la filosofía centrada en el servidor de HTMX, o prefieren, como yo, las respuestas JSON y la reactividad instantánea de Alpine.js? ¡Déjenos sus comentarios!
¿Quizás me distancié de HTMX demasiado pronto, antes de comprender su verdadero poder?