- Me gusta mucho la idea básica y simple de Htmx, pero después de usarlo en todo el equipo descubrieron que en la práctica no es simple y resulta bastante complejo.
La herencia de atributos en Htmx es claramente un error
- En fragmentos de código, la herencia de atributos es implícita y sorprendente.
- Como en CSS, la herencia es un truco barato, pero tiene un costo.
- Contradice la afirmación del autor sobre la localidad del comportamiento.
- La herencia predeterminada varía entre atributos (por ejemplo,
hx-delete no se hereda, pero hx-confirm y hx-ext sí).
- Hay que recordar las excepciones y terminar expresando todo de forma explícita, lo que vuelve inútil la herencia.
La mayoría de las aplicaciones web interesantes no pueden reemplazar por completo los elementos del DOM
- Los elementos del DOM casi siempre tienen estado local del navegador (por ejemplo, el estado abierto/cerrado de un elemento
<details>, el valor ingresado en un elemento <input>, o el estado abierto/cerrado de un elemento desplegable).
- Si Htmx usa el enfoque simple de reemplazar directamente
outerHTML, todo ese estado se pierde.
- La extensión Morphdom también sobrescribe algunos elementos de formas distintas a lo esperado.
Guardar estado en los propios elementos del DOM es una mala idea
- Morphdom intenta resolver el dolor del punto anterior, pero se descubrió que la forma de funcionar de Htmx se basa en reemplazar completamente los elementos.
- Guarda la cola de solicitudes en el propio elemento del DOM.
- Al iniciar una solicitud, ese elemento o algún otro que lo referencia mantiene la cola de solicitudes.
- Si se reemplaza completamente el elemento del DOM, la cola se reinicia y eso puede evitar algunos modos de fallo desagradables.
- Pero con Morphdom el elemento se conserva, por lo que la cola también permanece.
- Se entra en una especie de zona de comportamiento no definido donde se viola el diseño de Htmx.
El modo de encolado predeterminado es un desastre
- Por defecto, Htmx cancela una solicitud en curso si se dispara otra solicitud desde la misma cola (elemento).
- Esa es la estrategia predeterminada.
- Esto se descubrió después.
- No es nada intuitivo y significa perder trabajo.
Los disparadores de eventos no son locales
- Los disparadores de eventos a menudo ayudan a hacer que algo ocurra, pero son efectos no locales y tienen problemas similares a la herencia de atributos.
- Hacer trabajo de DSL en un lenguaje del lado del servidor puede ayudar un poco, pero se siente parecido a la vieja programación en JavaScript basada en callbacks.
- Ocurre un evento, uno se “suscribe” y hace algo.
No se puede mantener bien el estado de los componentes
- Un problema más amplio, similar al del estado de los elementos del DOM, es que tus propios componentes tienen su propio estado.
- Por ejemplo, si quieres una página compuesta por tres secciones con estado propio que necesita el servidor (por ejemplo, la página de un conjunto de resultados) y estado que requieren React o WebComponents, entonces aparece el problema de sincronizar el estado entre componentes padre e hijos.
- Htmx no ofrece una buena forma de manejar esto.
- Hay ideas como usar parámetros de consulta, campos ocultos de formulario, disparadores de eventos, etc., pero todas tienen grandes advertencias.
- React y Halogen sí tienen una respuesta para esto.
- En ambos casos, los componentes hijos tienen su propio estado y el padre puede proporcionar “props”, algo así como “sugerencias”.
- También tienen su propio estado interno, que puede ignorar o priorizar sobre las props.
- Las props generalmente provienen del servidor o se derivan de él, y el estado normalmente es del lado del cliente.
- Los componentes listos para usar que vienen con React, o que hay que usar, a menudo requieren React.
- React y Htmx no interactúan bien.
- Se hicieron cosas no del todo satisfactorias con WebComponents, pero tienen limitaciones extrañas y sorprendentes.
- También se intentó construir puentes directos a componentes de React usados desde un lenguaje del lado del servidor, pero en general Htmx y React pelean por el flujo de estado y la gestión de los elementos del DOM.
- Se probó Alpine y está bien, pero es otra biblioteca de programación del lado del cliente, así que si React ya está en la base de código resulta redundante.
Aun así, tiene ventajas
- Poder usar un lenguaje del lado del servidor es una ventaja enorme, obvia y nada controversial.
- Nadie en el equipo querría reescribir toda esa lógica de negocio en TypeScript.
- No hace falta serializar desde tipos de la base de datos hacia tipos del frontend.
- No hay fugas de datos ni hace falta GraphQL.
- Se pueden usar capacidades de abstracción más potentes del lenguaje del lado del servidor.
- En lugar de implementar tanto frontend como backend para la misma validación, se pueden usar los form builders del lado del servidor.
- Pero las desventajas de arriba también son reales.
¿Htmx dentro de React?
- Una dirección futura atractiva podría ser reimplementar Htmx en React.
- El servidor enviaría un blob de JSON y React lo convertiría en componentes del DOM virtual.
- Entonces se resolvería el problema del estado de los componentes.
- No harían falta puentes especiales para usar componentes de React.
- Se podrían usar bibliotecas de fetch web conectadas a React y evitar cuidadosamente una elección de encolado que Htmx tomó.
- También se resolverían los problemas de Morphdom y de los elementos de entrada del DOM del navegador, porque en React son problemas casi resueltos.
- Así se podría eliminar la dependencia de Htmx conservando las ventajas de la idea, siempre que se cuente con el presupuesto para iniciar un trabajo tan grande.
Opinión de GN⁺
- La idea básica de Htmx es atractiva, pero en el uso real puede enfrentar varios problemas complejos.
- Algunos aspectos del diseño de Htmx, como la herencia de atributos, el reemplazo de elementos del DOM y el modo de encolado, no son intuitivos y pueden provocar comportamientos inesperados.
- La integración con React o WebComponents tampoco parece sencilla.
- Aun así, poder usar un lenguaje del lado del servidor es una gran ventaja.
- En el futuro, reimplementar Htmx sobre React también podría ser una dirección interesante.
12 comentarios
El interés es mejor que la indiferencia~ A mí me gusta HTMX. También su filosofía.
Se parece muchísimo a SQLite en esa línea jaja
¿En qué se parecen SQLite y HTMX?
¿Parecido a SQLite?
El comentario es profundo. Filosofía...
Si tienes experiencia desarrollando para la web con renderizado del lado del servidor y jQuery antes de que aparecieran las SPA, entenderás de inmediato que va por esa línea tecnológica. Probablemente quienes empezaron en el desarrollo web con las SPA, al buscar algo nuevo, están malinterpretándolo.
No parece que este artículo haya sido escrito en Corea.
Sí, tal cual. Parece una herramienta hecha para páginas simples, así que no entiendo por qué surgen discusiones trayendo ejemplos raros o casos de uso extraños para decir que no encaja con eso.
Como se puede ver en la página principal de htmx, htmx adopta una postura cercana a que, si dependiera solo de ellos, no harían falta las tecnologías modernas de frontend, incluido React.
Eso tiene que ver con por qué htmx está recibiendo atención. Este texto también es una traducción de un artículo de colaboración extranjero, y afuera están cansados de toda clase de gestión de estado en React. Por eso vieron a htmx, que ofrece funciones parecidas a React pero que, a diferencia de React, no necesita gestión de estado, como un sustituto de React. Por eso siguen comparando htmx con React.
Pues bien, si esa es la razón, ¿no sería más correcto traer y comparar algo que sí afirme que puede reemplazar a React?
Con solo ver las características enumeradas en esta página, queda claro que HTMX no es algo pensado para entrar en páginas complejas, ni de ninguna manera algo que pueda reemplazar a React.
Opiniones en Hacker News
Hay opiniones divididas sobre la herencia de atributos. Se puede desactivar con la opción
htmx.config.disableInheritanceLa razón por la que no se metió en frontend es que hay demasiadas opciones, muchas críticas y las tendencias tecnológicas cambian con frecuencia
Está construyendo una storefront con buen rendimiento usando HTMX y está satisfecho con los resultados
La idea de "HTMX in React" es como reinventar React Server Components
No está de acuerdo con la opinión de que el modo de espera predeterminado sea irracional
Tras usar HTMX por primera vez, le pareció fácil de aplicar en tareas simples y fue divertido
Al leer las quejas sobre el estado, piensa que el autor nunca había creado sitios web antes de React
Se pregunta si HTMX tiene una función similar a Turbo Mount
Quiere saber más sobre el problema de que morphdom sobrescriba algunos elementos de forma inesperada
detailses una función principal de bibliotecas como morphdom