Uma das críticas mais comuns ao htmx, geralmente de quem ouve falar dele pela primeira vez, é mais ou menos assim:
Você está reclamando da complexidade das estruturas de front-end modernas, mas sua solução é apenas mais uma estrutura de front-end complexa.
Esta é uma excelente objeção! É o direito de questionar sobre qualquer código de terceiros (3P) que você introduzir em seu projeto. Mesmo que você não esteja escrevendo o código 3P sozinho, ao incluí-lo em seu projeto você está comprometido em entendê-lo – e atualizar esse entendimento se quiser atualizá-lo. Esse é um grande compromisso.
Vamos dividir essa crítica em suas partes constituintes e determinar exatamente até que ponto o htmx se entrega aos danos que afirma resolver.
A diferença entre uma biblioteca e um framework
Alguns defensores do htmx vêm em nosso auxílio dizendo: “htmx não é um framework, é uma biblioteca”. Isso provavelmente está incorreto.
“Framework” é um termo coloquial – não existe uma regra rígida para o ponto em que algum código de terceiros evolui de uma “biblioteca” para uma “framework” – mas ainda assim deveríamos tentar defini-lo. Nesse contexto:
- Biblioteca – código 3P cuja API não influencia significativamente o resto da aplicação
- Framework – código 3P cuja API dita a estrutura geral do aplicativo
Se você preferir metáforas: uma biblioteca é uma engrenagem que você adiciona à sua máquina, um framework é uma máquina pré-construída que você controla personalizando suas engrenagens.
Essa distinção, por mais confusa que seja, é importante porque descreve a facilidade com que alguns códigos de terceiros podem ser substituídos. Por exemplo, um serviço JavaScript que usa uma biblioteca de análise CSV provavelmente pode trocar por uma biblioteca de análise CSV diferente sem muitos problemas; um serviço JavaScript que usa a estrutura NextJS, no entanto, provavelmente dependerá do NextJS durante toda a sua vida útil, já que uma grande parte do código é escrita com a suposição de que está interagindo com construções NextJS.
Portanto, se o seu serviço for construído sobre uma estrutura, sua vida útil estará vinculada à vida útil dessa estrutura. Se essa estrutura for abandonada, ou desprezada, ou de outra forma indesejável para trabalhar, a dificuldade de modificar seu projeto aumentará constantemente até que você desista de modificá-lo e, eventualmente, desative-o completamente.
É com isso que as pessoas ficam preocupadas quando perguntam “o htmx é apenas mais um framework JavaScript?” Eles querem ter certeza de que não estão se comprometendo com um sistema que ficará obsoleto em breve, como muitos dos frameworks de desenvolvimento web anteriores.
Então: htmx é um framework? E será que se tornará obsoleto rapidamente, deixando um rastro de sites insustentáveis após seu desaparecimento meteórico?
htmx é (geralmente) um framework
Peço desculpas ao debate contínuo da nossa comunidade sobre esta questão – acho que htmx é claramente uma estrutura, pelo menos na maioria dos casos de uso. Mas isso depende de como você o usa.
Onde quer que você use htmx em seu projeto, você estará incluindo atributos htmx em seu HTML (ou seja hx-post, hx-target), escrevendo endpoints que são chamados com dados formatados em htmx (com determinados cabeçalhos de solicitação) e retornando dados desses endpoints formatados da maneira que o htmx espera (HTML com hx-*controles). Todos esses atributos, cabeçalhos e terminais interagem entre si para criar um sistema pelo qual os elementos entram e saem do DOM por meio de solicitação de rede.
Se você usar htmx para lidar com um número não trivial de solicitações de rede do seu site, a inclusão de htmx em seu aplicativo terá implicações significativas para a estrutura do projeto, desde a maneira como você estrutura sua marcação de front-end até as consultas de banco de dados que seus endpoints fazem. Esse é um comportamento semelhante ao de uma estrutura e, nesse cenário, o htmx não pode ser substituído trivialmente.
Definitivamente, você pode usar o htmx como uma biblioteca, para adicionar funcionalidade dinâmica a apenas algumas seções da sua página da web. Mas você também pode escrever o React dessa maneira semelhante a uma biblioteca e ninguém argumenta que o React não é um framework. Basta dizer que muitas pessoas que usam htmx em seus aplicativos o fazem de uma forma que atende às demandas do htmx, como uma estrutura para a construção de aplicativos hipermídia.
Como deveriam! Construir com htmx funciona muito melhor se você aproveitar seus pontos fortes. Você pode enviar corpos de formulários no formato JSON, se realmente insistir. Mas você não deveria! É mais simples usar apenas application/x-www-form-urlencodedcorpos e escrever um endpoint que os aceite. Você pode escrever um endpoint que seja reutilizado em vários clientes diferentes, se você realmente insistir. Mas você não deveria! É mais simples dividir seus dados e APIs de hipermídia em URLs separados. Sim, o htmx pode ser usado como uma biblioteca, mas talvez seja o seu framework também.
Isso não significa, entretanto, que o htmx seja apenas mais um framework JavaScript, porque o htmx tem uma enorme vantagem que os outros frameworks não têm: HTML.
htmx é para escrever HTML
Digamos que você esteja usando htmx como framework – é um framework JavaScript ? Em um sentido óbvio, sim: htmx é implementado com aproximadamente 4k linhas de JS. Mas em outro sentido, muito mais importante, não é: React, Svelte, Solid e assim por diante você escreve JS(X) que o framework converte em HTML; htmx apenas você escreve HTML. Isso remove categorias inteiras de manutenção que podem fazer você abandonar outras estruturas com o tempo.
As bases de código tendem a travar quando você deseja atualizar ou alterar alguma dependência, mas o framework que você usa é incompatível com essa mudança. Java é o infrator mais notório aqui – há milhões de linhas de Java em produção que nunca sairão do Java 8 porque atualizar o Spring é muito difícil – mas o ecossistema de pacotes npm está em segundo lugar. Ao usar a “estrutura” htmx, você nunca terá esse problema, porque htmx é um arquivo JavaScript carregado pelo cliente e com dependência zero, portanto, é garantido que nunca entrará em conflito com qualquer processo de construção ou cadeia de dependência da qual seu servidor depende .
Os navegadores renderizam HTML, portanto, nenhum compilador ou transpilador é necessário para trabalhar com htmx. Embora muitos usuários de htmx renderizem respostas de API com JSX, o htmx funciona muito bem com mecanismos de modelo clássicos, tornando-o portável para qualquer linguagem de sua preferência. Diga o que quiser sobre Django e Rails, mas eles eram relevantes em 2008 e são relevantes hoje – o htmx integra-se perfeitamente com ambos. Este é um tema recorrente no desenvolvimento orientado a htmx: htmx funciona bem com ferramentas de desenvolvimento antigas e novas, porque o denominador comum em todas essas ferramentas é HTML, e htmx é para escrever HTML.
Forçar o usuário a definir o comportamento de seu aplicativo principalmente em HTML, em vez de JS, tem muitas vantagens a serem abordadas neste ensaio, então vou me ater ao que as pessoas mais odeiam nos famosos trabalhos em JavaScript: a rotatividade. Dependendo de quando você escreveu seu aplicativo React, você pode ter escrito seu formulário com componentes de classe controlada, ou ganchos de reação, ou esta extensão experimental<form> . Isso é realmente enlouquecedor, especialmente se você – como eu – aprendeu como fazer um formulário web com componentes de classe.
No entanto, não importa quando você escreveu seu aplicativo htmx, o comportamento de um formulário htmx sempre foi definido basicamente da mesma maneira que um formulário HTML normal: com <form>. Com o htmx adicionando funcionalidade de rede adicional, você pode finalmente usar PUTsolicitações e controlar para onde vai a resposta, mas em todos os outros aspectos – validação, entradas, rótulos, preenchimento automático – você tem um <form>comportamento de elemento padrão.
Finalmente, como o htmx simplesmente estende o HTML em um domínio muito restrito (solicitações de rede e substituições de DOM), a maior parte do “htmx” que você escreve é simplesmente HTML antigo. Quando você tem acesso a mecanismos complexos de gerenciamento de estado, é incrivelmente fácil implementar um div recolhível personalizado; caso contrário, você poderá parar por tempo suficiente para pesquisar o <details> elemento. Sempre que um problema pode ser resolvido por elementos HTML nativos, a longevidade do código melhora tremendamente. Esta é uma maneira muito menos alienante de aprender desenvolvimento web, porque a maior parte do seu conhecimento permanecerá relevante enquanto o HTML permanecer.
Nesse aspecto, htmx é muito mais parecido com JQuery do que React (o antecessor do htmx, intercooler.js , era uma extensão JQuery), mas melhora o JQuery usando uma interface declarativa baseada em HTML: onde JQuery fez você acessar a <script>tag para especificar o comportamento AJAX, o htmx requer apenas um hx-postatributo simples.
Resumindo, embora o htmx possa ser usado como um framework, é um framework que se desvia muito menos da semântica da web do que os frameworks JavaScript, e se beneficiará de melhorias nessas semânticas sem nenhum trabalho adicional do usuário, graças ao excelente desempenho da web. garantias de compatibilidade com versões anteriores. Se você deseja construir um site que dure muito tempo, essas qualidades tornam o htmx uma aposta substancialmente melhor do que muitos de seus contemporâneos.