Uma crítica moderada ao Htmx

(chrisdone.com)

7 pontos por GN⁺ 2024-10-10 | 12 comentários | Compartilhar no WhatsApp

Gosto muito da ideia básica e simples do Htmx, mas, depois de usá-lo em toda a equipe, descobrimos que, na prática, ele não é simples e é bastante complexo

A herança de atributos do Htmx é claramente um erro

Em trechos de código, a herança de atributos é implícita e surpreendente
Como no CSS, herança é um hack barato, mas tem seu preço
Isso contradiz o argumento de localidade de comportamento do autor
O padrão de herança varia entre vários atributos (ex.: hx-delete não é herdado, mas hx-confirm e hx-ext são)
É preciso memorizar exceções e acabar expressando tudo explicitamente, o que torna a herança sem sentido

A maioria dos web apps interessantes não pode substituir elementos DOM por completo

Elementos DOM quase sempre têm estado local do navegador (ex.: estado aberto/fechado de um elemento <details>, valor digitado em um elemento <input>, estado aberto/fechado de elementos de dropdown)
Quando o Htmx usa a abordagem simples de substituir diretamente o outerHTML, todo esse estado se perde
A extensão Morphdom também sobrescreve alguns elementos de forma diferente do esperado

Armazenar estado no próprio elemento DOM é uma má ideia

O Morphdom é uma tentativa de resolver o problema do tópico anterior, mas descobriu-se que a forma como o Htmx funciona se baseia em substituir elementos por completo
A fila de requisições é armazenada no próprio elemento DOM
Ao iniciar uma requisição, esse elemento — ou outro elemento que aponte para ele — passa a ter a fila de requisições
Se o elemento DOM for substituído por completo, a fila é reiniciada, o que pode evitar alguns modos ruins de falha
Porém, com Morphdom, o elemento é preservado e, portanto, a fila também
Isso deixa o sistema numa espécie de área de comportamento indefinido, em que o design do Htmx é violado

O modo de enfileiramento padrão é uma bagunça

Por padrão, no Htmx, se outra requisição for disparada na mesma fila (elemento), a requisição em andamento é cancelada
Essa é a estratégia padrão
Descobri isso só mais tarde
É muito pouco intuitivo e significa perder trabalho

Gatilhos de evento não são locais

Gatilhos de evento frequentemente ajudam a fazer algo acontecer, mas têm efeitos não locais e problemas parecidos com os da herança de atributos
Trabalhar com DSL no lado do servidor pode ajudar um pouco nisso, mas a sensação é parecida com a velha programação em JavaScript baseada em callbacks
Quando um evento acontece, você “assina” e executa alguma ação

Não é possível manter bem o estado de componentes

Um problema mais amplo, semelhante ao problema do estado de elementos DOM, é que seus próprios componentes têm estado próprio
- Por exemplo, se você quiser uma página composta por três seções, com estado próprio necessário no servidor (como a página de um conjunto de resultados) e estado exigido por React ou WebComponents, surge o problema de sincronizar o estado entre componente pai e componentes filhos
O Htmx não oferece uma boa forma de lidar com isso
- Existem ideias como usar parâmetros de consulta, inputs ocultos de formulário, gatilhos de evento etc., mas todas têm grandes ressalvas
React e Halogen têm uma resposta para isso
- Em ambos os casos, os componentes filhos têm seu próprio estado, e o pai pode fornecer props, como “conselhos”
- Eles também têm seu próprio estado interno e podem ignorar ou priorizar esse estado em relação às props
- As props geralmente são fornecidas pelo servidor ou derivadas dele, e o estado normalmente é estado do lado do cliente
Componentes prontos fornecidos em React, ou componentes que você precisa usar, frequentemente exigem React
- React e Htmx não interagem bem
- Já fiz trabalhos pouco satisfatórios com WebComponents, mas eles têm limitações bizarras e surpreendentes
- Também já criei bridges diretas para componentes React usados a partir da linguagem do lado do servidor, mas, em geral, Htmx e React brigam pelo fluxo de estado e pelo gerenciamento de elementos DOM
- Testei Alpine, e ele é bom, mas é mais uma biblioteca de programação do lado do cliente, então é redundante quando React já está no codebase

Mesmo assim, há vantagens

Poder usar uma linguagem do lado do servidor é uma vantagem enorme, óbvia e incontestável
Ninguém da equipe gostaria de reescrever toda essa lógica de negócio em TypeScript
Não é necessário serializar dos tipos do banco de dados para tipos de frontend
- Não há vazamento de dados e também não é preciso GraphQL
É possível usar os recursos de abstração mais poderosos da linguagem do lado do servidor
Em vez de implementar a mesma validação tanto no frontend quanto no backend, você pode usar os form builders da linguagem do lado do servidor
Mas as desvantagens acima também são reais

Htmx-in-React?

Uma direção futura atraente pode ser reimplementar o Htmx em React
- O servidor enviaria um blob JSON, e o React o transformaria em componentes de virtual DOM
- Assim, o problema do estado de componentes seria resolvido
- Não seria necessário um bridge especial para usar componentes React
- Seria possível usar bibliotecas React conectadas a web fetching e evitar cuidadosamente uma escolha de enfileiramento feita pelo Htmx
- Os problemas do Morphdom e dos elementos de input do DOM no navegador também seriam resolvidos, já que isso é praticamente um problema já resolvido no React
Dessa forma, seria possível remover a dependência de Htmx e ainda preservar os benefícios da ideia. Claro, isso exigiria orçamento para iniciar um trabalho desse porte

Opinião do GN⁺

A ideia básica do Htmx é atraente, mas, no uso real, pode esbarrar em vários problemas complexos
Alguns aspectos do design do Htmx, como herança de atributos, substituição de elementos DOM e modo de enfileiramento, não são intuitivos e podem provocar comportamentos inesperados
A integração com React ou WebComponents também não parece simples
Ainda assim, poder usar linguagens do lado do servidor é uma grande vantagem
No futuro, reimplementar o Htmx com base em React também pode ser um caminho interessante

12 comentários

felizgeek 2024-10-10

Interesse é melhor do que indiferença~ Eu gosto de HTMX. Da filosofia também.
Também tem uma vibe bem parecida com SQLite kkk

savvykang 2024-10-13

Em que aspectos SQLite e HTMX são parecidos?

aer0700 2024-10-12

Parecido com o SQLite?

halfenif 2024-10-11

O comentário é profundo. Filosofia, hein..

2024-10-10

[Este comentário foi ocultado.]

savvykang 2024-10-10

Se você já teve experiência com desenvolvimento web com renderização no lado do servidor & jQuery antes do surgimento das SPAs, vai entender de imediato que se trata desse tipo de tecnologia. Talvez quem começou no desenvolvimento web já pela era das SPAs, ao buscar algo novo, esteja se confundindo.

heycalmdown 2024-10-10

Não parece que este texto tenha sido escrito na Coreia.

ndrgrd 2024-10-10

Pois é. Parece ser uma ferramenta feita para páginas simples, então não entendo por que surgem discussões trazendo exemplos estranhos ou casos de uso e dizendo que ela não serve para isso.

roxie 2024-10-11

Como dá para perceber pela página principal do htmx, o htmx adota uma posição próxima à de que, se dependesse apenas deles, tecnologias modernas de front-end, incluindo React, não seriam necessárias.

rlrsbtm80879 2024-10-10

Isso tem a ver com o motivo pelo qual o htmx está recebendo atenção. Este texto também é uma tradução de um artigo estrangeiro, e lá fora as pessoas estão cansadas de todo tipo de gerenciamento de estado no React. Por isso, passaram a ver o htmx, que oferece recursos parecidos com os do React, mas não exige gerenciamento de estado como o React, como uma alternativa ao React. É por isso que continuam comparando o htmx com o React.