HTMX é o futuro

O estado atual do desenvolvimento de aplicativos da web

As expectativas do usuário da Web são agora que você tem essa experiência sem recarga super suave. Infelizmente, é uma expectativa que geralmente é entregue com aplicativos de página única (SPAs) que dependem de bibliotecas e estruturas como React e Angular, que são ferramentas muito especializadas que podem ser complicadas de se trabalhar.

Uma nova abordagem é colocar a capacidade de entregar esse UX de volta nas mãos dos engenheiros que criaram sites antes da mania do SPA, aproveitando seus conjuntos de ferramentas e conhecimentos existentes, e o HTMX é o melhor exemplo que usei até agora.

Os custos do SPA

Os SPAs permitiram que os engenheiros criassem ótimos aplicativos da Web, mas eles têm um custo:

• Complexidade extremamente aumentada em termos de arquitetura e experiência do desenvolvedor. Você tem que gastar um tempo considerável aprendendo sobre frameworks.
  • O ferramental é um cenário em constante mudança em termos de código de construção e embalagem.
  • Gerenciando o estado no cliente e no servidor
  • Frameworks, em cima de bibliotecas, em cima de outras bibliotecas, em cima de polyfills. O React até recomenda o uso de um framework em cima de sua tecnologia:

React é uma biblioteca. Ele permite que você junte componentes, mas não prescreve como fazer roteamento e busca de dados. Para criar um aplicativo inteiro com o React, recomendamos uma estrutura React de pilha completa.

• Por sua natureza, um fat client exige que o cliente execute muito JavaScript. Se você tiver um hardware moderno, tudo bem, mas esses aplicativos serão inutilizáveis ​​e lentos para aqueles com hardware mais antigo ou em locais com conexões de internet lentas e não confiáveis.
  • É muito fácil fazer um SPA incorretamente, onde você precisa usar a abordagem certa com ganchos para evitar acabar com um péssimo desempenho do lado do cliente.
• Algumas implementações SPA do SPA descartam o aprimoramento progressivo (uma exceção notável e nobre é o Remix ). Portanto, você deve ter o JavaScript ativado para a maioria dos SPAs.
• Se você deseja usar algo diferente de JavaScript ou TypeScript, deve percorrer o caminho traiçoeiro da transpilação.
• Ele criou silos de back-end e front-end em muitas empresas, acarretando altos custos de coordenação.

Antes dos SPAs, você escolheria seu idioma preferido e entregaria HTML ao navegador de um usuário em resposta a solicitações HTTP. Isso é bom , mas oferece pouca interatividade e, em alguns casos, pode tornar a interface do usuário irritante de usar, especialmente em relação ao recarregamento completo da página a cada interação. Para contornar isso, você normalmente borrifaria quantidades variadas de JS para lubrificar as rodas do UX.

Embora essa abordagem possa parecer antiquada para alguns, essa abordagem foi o que inspirou o artigo original do REST, especialmente no que diz respeito à hipermídia . A abordagem hipermídia de construção de sites levou a world wide web a ser um sucesso incrível.

Hipermídia?

O seguinte é uma resposta de uma API de dados, não hipermídia.

{
  "sort": "12-34-56",
  "number": "87654321",
  "balance": "123.45"
}

Para tornar esses dados úteis em um SPA, o código do cliente deve entender a estrutura e decidir o que renderizar e quais controles disponibilizar.

REST descreve o uso de hipermídia. A hipermídia é onde suas respostas não são apenas dados brutos, mas sim uma carga útil que descreve a mídia (pense em tags HTML como <p>, cabeçalhos etc.) e como manipulá-la (como form, input).

Um servidor que retorna HTML descrevendo uma conta bancária, com algum tipo de controle para trabalhar com o recurso, é um exemplo de hipermídia. O servidor agora é responsável por decidir como renderizar os dados (com a pequena ressalva do CSS) e quais controles devem ser exibidos.

<dl>
  <dt>Sort</dt><dd>12-34-56</dd>
  <dt>Number</dt><dd>87654321</dd>
  <dt>Balance</dt><dd>£123.45</dd>
</dl>
<form method="POST" action="/transfer-funds">
  <label>Amount <input type="text" /></label>
  <!-- etc -->
  <input type="submit" value="Do transfer" />
</form>

A abordagem significa que você tem um cliente universal, o navegador da web; ele entende como exibir as respostas da hipermídia e permite que o usuário trabalhe com os “controles” para fazer o que precisar.

Carson Gross no podcast Go Time

…quando os navegadores surgiram, essa ideia de um cliente de rede universal que pudesse se comunicar com qualquer aplicativo por meio dessa tecnologia hipermídia maluca era muito, muito nova. E ainda é.

Se você dissesse a alguém em 1980: “Sabe de uma coisa, você usará o mesmo software para acessar suas notícias, seu banco, sua agenda, essas coisas chamadas e-mail e todas essas coisas”, eles teriam olhado para você vesgo, eles não saberiam do que você está falando, a menos que estivessem em um dos pequenos grupos de pesquisa que estavam investigando esse tipo de coisa.

Antes da World Wide Web, antes dos navegadores da web, os padrões predominantes de aplicativos eram clientes sob medida e, muitas vezes, “grossos”.

Embora ostensivamente as pessoas que constroem SPAs falem sobre o uso de APIs “RESTful” para fornecer troca de dados para seu código do lado do cliente, a abordagem não é RESTful no sentido purista porque não usa hipermídia.

Em vez de um cliente universal, dezenas de desenvolvedores criam clientes sob medida , que precisam entender os dados brutos que buscam nos servidores da Web e, em seguida, renderizar os controles de acordo com os dados. Com essa abordagem, o navegador é mais um tempo de execução de JavaScript, HTML e CSS.

Por definição, um cliente mais gordo terá mais esforço e custo do que um magro. No entanto, a abordagem de hipermídia “original” sem dúvida não é boa o suficiente para todas as necessidades de hoje; os controles com os quais o navegador pode trabalhar e a maneira como ele requer uma atualização completa da página para usá-los significam que a experiência do usuário não é boa o suficiente para muitos tipos de aplicativos da web que precisamos criar.

HTMX e hipermídia

Ao contrário dos SPAs, o HTMX não descarta a abordagem arquitetônica do REST ; ele aumenta o navegador , melhorando seus recursos de hipermídia e simplificando a entrega de uma experiência de cliente rica sem ter que escrever muito JavaScript, se é que precisa escrever algum.

Você pode usar qualquer linguagem de programação que desejar para fornecer HTML, como costumávamos fazer. Isso significa que você pode usar ferramentas maduras e testadas em batalha, usando uma abordagem “verdadeira RESTful”, resultando em uma abordagem de desenvolvimento muito mais direta com menos complexidade acidental.

O HTMX permite que você crie páginas que buscam fragmentos de HTML de seu servidor para atualizar a página do usuário conforme necessário, sem a irritante atualização de carregamento de página inteira.

Agora veremos isso na prática com o clássico aplicativo TODO-list.

Clojure HTMX TODO

Em primeiro lugar, por favor, não se preocupe muito com isso sendo escrito em Clojure. Fiz isso em Clojure por diversão, mas a beleza dessa abordagem é que você pode usar qualquer linguagem que desejar, desde que responda a solicitações HTTP com hipermídia.

Nada de especial aqui, mas parece um SPA . Não há recargas de página inteira; é suave como manteiga, assim como todas as outras demonstrações de SPA que você já viu.

A diferença aqui é:

• Eu não escrevi nenhum JavaScript.
• Também não trapaceei ao transpilar Clojure para JavaScript. (consulte ClojureScript )

Fiz um servidor web que responde a requisições HTTP com hipermídia.

O HTMX adiciona a capacidade de definir hipermídia mais rica , permitindo que você anote qualquer elemento HTML para solicitar ao navegador que faça solicitações HTTP para buscar fragmentos de HTML para colocar na página.

O controle de edição

A parte mais emocionante e impressionante desta demonstração é a ação de edição. A maneira como uma caixa de entrada aparece instantaneamente para você editar e, em seguida, atualizá-la rapidamente novamente, parece que exigiria muita escrita JS de baunilha ou uma abordagem no estilo React para ser alcançada, mas o que você verá é que é absurdamente simples.

Vamos começar examinando a marcação de um item TODO. Cortei a marcação de não edição para maior clareza.

<li hx-target="closest li">
  <form action="/todos/2a5e549c-c07e-4ed5-b7d4-731318987e05" 
      method="GET">
      <button 
        hx-get="/todos/2a5e549c-c07e-4ed5-b7d4-731318987e05" 
        hx-swap="outerHTML">
        📝</button>
  </form>
</li>

Pode parecer muito, mas as principais coisas a serem observadas para entender como funciona a funcionalidade de edição:

• No <li>, um atributo hx-targetinforma ao navegador: “Quando você obtiver um fragmento para renderizar, este é o elemento que desejo que você substitua”. Os filhos herdam esse atributo, portanto, para qualquer ação HTMX dentro deste <li>, o HTMLretornado substituirá o conteúdo do <li>.
• hx-getno botão de edição significa que quando você clicar nele, HTMXdirá ao navegador para fazer um HTTP GETpara o URLe buscar alguma nova marcação para renderizar no <li>lugar do que está lá.
• O formulário não é essencial para o exemplo, mas nos permite oferecer suporte à funcionalidade para usuários não JavaScript, que serão abordados posteriormente.

Quando você começa a trabalhar com HTMX, uma maneira fácil de entender o que está acontecendo é observar a rede nas ferramentas de desenvolvedor do navegador.

Quando um usuário clica no botão de edição, o navegador faz um HTTP GETpara o recurso de tarefa específico . O servidor retorna uma resposta de hipermídia, que é uma representação desse recurso com alguns controles de hipermídia.

<form action="/todos/45850279-bf54-4e2e-a95c-c8c25866a744/edit"
      hx-patch="/todos/45850279-bf54-4e2e-a95c-c8c25866a744" 
      hx-swap="outerHTML" method="POST">
  <input name="done" type="hidden" value="false"/>
  <input name="name" type="text" value="Learn Rust"/>
  <input type="submit"/>
</form>

O HTMX pega esse HTML e substitui o que definimos como o arquivo hx-target. Assim, o usuário agora vê esses controles de hipermídia para manipular o recurso, em vez da linha mostrada anteriormente.

Você notará que o formulário possui um hx-patchatributo, ou seja, quando for enviado, o navegador enviará um PATCHcom os dados para atualizar o recurso. O servidor então responde com o item atualizado a ser renderizado.

Abraçando a web

Há mais no HTMX, mas esse é o cerne da abordagem, que é a mesma que a maioria dos sites usava antes de os SPAs se tornarem populares.

• O usuário vai para umURL
• O servidor retorna hipermídia (HTML), que se contenta com controles.
• Navegador renderiza hipermídia
• Os usuários podem usar os controles para fazer o trabalho, o que resulta em uma solicitação HTTP enviada do navegador para o servidor.
• O servidor faz a lógica de negócios e, em seguida, retorna uma nova hipermídia para o usuário trabalhar.

Tudo o que o HTMX faz é melhorar o navegador em hipermídia, dando-nos mais opções sobre o que pode acionar uma solicitação HTTP e nos permitindo atualizar uma parte da página em vez de recarregar a página inteira .

Ao adotar a hipermídia e não visualizar o navegador apenas como um tempo de execução do JavaScript, obtemos muitos benefícios de simplicidade:

• Podemos usar qualquer linguagem de programação no lado do servidor.
• Não precisamos de muitas bibliotecas e outras porcarias para manter o que eram os benefícios básicos do desenvolvimento web.
  • Cache
  • facilidade de SEO
  • O botão Voltar funcionando como você esperaria
  • etc.
• É muito fácil oferecer suporte a usuários que não desejam ou não podem usar JavaScript

Este ponto final é crucial para mim e para meu empregador atual. Trabalho para uma empresa que trabalha com produtos usados ​​em todo o mundo, e nosso conteúdo e ferramentas devem ser utilizáveis ​​pelo maior número de pessoas possível. É inaceitável para nós excluir pessoas por meio de escolhas técnicas inadequadas.

É por isso que adotamos a abordagem de aprimoramento progressivo.

O aprimoramento progressivo é uma filosofia de design que fornece uma linha de base de conteúdo e funcionalidade essenciais para o maior número possível de usuários, ao mesmo tempo em que oferece a melhor experiência possível apenas para usuários dos navegadores mais modernos que podem executar todo o código necessário.

Todos os recursos do aplicativo TODO (pesquisar, adicionar, editar, excluir, marcar como concluído) funcionam com o JavaScript desativado. O HTMX não faz isso “de graça”, ainda requer esforço de engenharia, mas por causa da abordagem, é inerentemente mais simples de alcançar. Levei cerca de uma hora de esforço e não exigiu mudanças significativas.

Como ele suporta não-JavaScript

Quando o navegador envia uma solicitação solicitada pelo HTMX, ele adiciona um cabeçalho HX-Request: true, o que significa que no servidor podemos enviar diferentes respostas de acordo, muito parecido com a negociação de conteúdo.

A regra de ouro para um manipulador é aproximadamente:

parseAndValidateRequest()
myBusinessLogic()

if request is htmx then
    return hypermedia fragment
else
    return a full page
end

Aqui está um exemplo concreto do manipulador HTTP para lidar com um novo TODO:

(defn handle-new-todo [get-todos, add-todo]
  (fn [req] (let [new-todo (-> req :params :todo-name)]
              (add-todo new-todo)
              (htmx-or-vanilla req
                               (view/todos-fragment (get-todos))
                               (redirect "/todos")))))

A terceira linha é a nossa “lógica de negócios”, chamando uma função para adicionar um novo TODO à nossa lista.

A quarta linha é algum código para determinar com que tipo de solicitação estamos lidando e as linhas subsequentes renderizam um fragmento para retornar ou redirecionar para a página.

Até agora, esse parece ser um tema recorrente quando desenvolvo aplicativos hipermídia com HTMX. Pela própria natureza arquitetônica, se você puder suportar a atualização de parte de uma página, retorne um fragmento; caso contrário, o navegador precisa recarregar a página inteira, portanto, redirecione ou apenas retorne o HTML inteiro.

A modelagem HTML no servidor está em um estado incrivelmente maduro. Existem muitas opções e excelentes guias de como estruturar e adicionar testes automatizados para eles. É importante ressaltar que todos eles oferecem alguns recursos de composição, portanto, o esforço para retornar um fragmento ou uma página inteira é extremamente simples.

Por que é o Futuro ?

Obviamente, não posso prever o futuro, mas acredito que o HTMX (ou algo parecido) se tornará uma abordagem cada vez mais popular para a criação de aplicativos da Web nos próximos anos.

Recentemente, o HTMX foi anunciado como um dos 20 projetos no GitHub Accelerator

Isso torna o “frontend” mais acessível.

Aprender React é uma indústria em si. Ele se move rapidamente e muda, e há muito o que aprender. Eu simpatizo com os desenvolvedores que costumavam criar aplicativos completos sendo adiados pelo desenvolvimento de front-end moderno e, em vez disso, ficaram felizes por serem rotulados como um desenvolvedor de “back-end”.

Eu fiz sistemas razoavelmente complexos em React e, embora alguns deles tenham sido bem divertidos, a quantidade que você precisa aprender para ser eficaz não é razoável para a maioria dos aplicativos . O React tem seu lugar, mas é um exagero para muitos aplicativos da web.

A abordagem de hipermídia com HTMX não é difícil de entender, especialmente se você tiver alguns fundamentos REST (que muitos desenvolvedores de “back-end” deveriam ter). Ele abre a criação de sites ricos para um grupo mais amplo de pessoas que não querem aprender a usar uma estrutura e, em seguida, acompanhar seu cenário em constante mudança.

Menos rotatividade

Mesmo depois de mais de 10 anos de React por aí, ainda não parece estabelecido e maduro. Alguns anos atrás, os ganchos eram a novidade que todos tinham que aprender e reescrever todos os seus componentes. Nos últimos seis meses, meu feed do Twitter foi inundado com debates e tutoriais sobre esse novo “RSC” – componentes de servidor de reação. Emoji de alegria.

Trabalhar com HTMX me permitiu aproveitar coisas que aprendi há 15 a 20 anos e que ainda funcionam , como meu site. A abordagem também é bem compreendida e documentada, e as melhores práticas são independentes de linguagens de programação e estruturas.

Eu criei o aplicativo de exemplo em Go e Clojure sem nenhum problema e sou um novato completo em Clojure. Depois de descobrir a sintaxe básica de uma linguagem e aprender como responder a solicitações HTTP com hipermídia, você terá o suficiente para prosseguir; e você pode reutilizar as melhores práticas de arquitetura e design sem ter que aprender uma nova abordagem repetidas vezes.

Quanto de suas habilidades seriam transferíveis do React se você tivesse que trabalhar com o Angular? É fácil mudar de uma estrutura de reação para outra? Como você se sentiu quando os componentes de classe ficaram “ruins” e todos queriam que você usasse ganchos?

Mais barato

É apenas menos esforço!

Hotwire é uma biblioteca com objetivos semelhantes ao HTMX, impulsionada pelo mundo Ruby on Rails. DHH twittou o seguinte.

Hotwiring Rails expressa o desejo de presentear um desenvolvedor full-stack solitário com todas as ferramentas necessárias para construir o próximo Basecamp, GitHub ou Shopify. Não é o que uma equipe de dezenas ou centenas pode fazer se tiver milhões em VC para comprar especialistas. Tecnologia renascentista para pessoas renascentistas.

É por isso que é tão deprimente ouvir o termo “full stack” ser usado como depreciativo. Ou uma missão impossível. Que TEMOS que ser um bando disperso de front-end vs back-end vs serviços vs qualquer grupo de especialistas para fazer coisas legais. Absolutamente não.

Sem a sobrecarga cognitiva de entender uma vasta estrutura do mundo do SPA e as complexidades inerentes de criar um cliente gordo, você pode criar aplicativos Web avançados de forma realista com muito menos engenheiros.

Mais resiliente

Conforme descrito anteriormente, usando a abordagem hipermídia, criar um aplicativo da Web que funcione sem JavaScript é relativamente simples.

Também é importante lembrar que o navegador é um ambiente não confiável , portanto, ao criar um SPA, você deve trabalhar de forma extremamente defensiva. Você tem que implementar muita lógica de negócios do lado do cliente; mas por causa da arquitetura, essa mesma lógica também precisa ser replicada no servidor.

Por exemplo, digamos que queremos uma regra dizendo que você não pode editar uma tarefa se ela estiver marcada como concluída. Em um mundo SPA, eu obteria JSON bruto e teria que ter lógica de negócios para determinar se deveria renderizar o botão de edição no código do cliente em algum lugar. No entanto, se quiséssemos garantir que um usuário não pudesse contornar isso, eu teria que ter essa mesma proteção no servidor. Isso parece simples e de baixo risco, mas essa complexidade aumenta e a chance de desalinhamento aumenta.

Com uma abordagem hipermídia, o navegador é “burro” e não precisa se preocupar com isso. Como desenvolvedor, posso capturar essa regra em um só lugar, o servidor.

Complexidade de coordenação reduzida

A complexidade dos SPAs criou uma mudança para silos de back-end e front-end , o que acarreta um custo.

A divisão típica da equipe back-end/front-end causa muitas ineficiências em termos de trabalho em equipe, com transferências e falta de comunicação, e torna mais difícil fazer as coisas . Muitas pessoas confundem as eficiências individuais como a métrica mais crítica e usam isso como justificativa para esses silos. Eles veem muitos PRs sendo fundidos e muito calor sendo gerado, mas ignorando os custos de coordenação.

Por exemplo, vamos supor que você deseja adicionar um novo dado a uma página ou adicionar um novo botão. Para muitas equipes, isso envolverá reuniões entre as equipes para discutir e concordar com a nova API, criando falsificações para a equipe de front-end usar e, finalmente, coordenar os lançamentos.

Na abordagem hipermídia, você não tem essa complexidade . Se você deseja adicionar um botão à página, pode adicioná-lo e não precisa coordenar esforços. Você não precisa se preocupar tanto com o design da API. Você é livre para alterar a marcação e o conteúdo como quiser.

As equipes que trocam dados via JSON podem ser extremamente frágeis sem cuidado e sempre carregam um custo de coordenação. Ferramentas como contratos orientados ao consumidor podem ajudar, mas esta é apenas outra ferramenta, outra coisa para entender e outra coisa que dá errado. As despesas gerais, o suporte e a complexidade do controle de versão da API não são inerentemente um problema com uma abordagem de hipermídia; você é livre para alterar a marcação como quiser.

Isso não quer dizer que não haja espaço para especialização. Trabalhei em equipes em que os engenheiros criaram o aplicativo da Web “ponta a ponta”, mas tínhamos pessoas especialistas em marcação semântica e acessível que nos ajudaram a garantir que o trabalho que fazíamos fosse de boa qualidade. É incrivelmente libertador não ter que negociar APIs e entregar o trabalho uns aos outros para construir um site.

Mais opções

A renderização de HTML no servidor é uma estrada muito bem trilhada. Muitas ferramentas e bibliotecas maduras e testadas em batalha estão disponíveis para gerar HTML a partir do servidor em todas as linguagens de programação convencionais e na maioria das linguagens de nicho.

Empacotando

Encorajo os desenvolvedores que procuram reduzir os custos e as complexidades do desenvolvimento de aplicativos da Web a verificar o HTMX. Se você está relutante em construir sites devido à avaliação justa de que o desenvolvimento front-end é difícil, o HTMX pode ser uma ótima opção.

Não estou tentando afirmar que os SPAs agora são redundantes; ainda haverá uma necessidade real deles quando você precisar de interações muito sofisticadas e rápidas, nas quais uma viagem de ida e volta ao servidor para obter alguma marcação não será boa o suficiente.

Em 2018, afirmei que um número considerável de aplicativos da Web poderia ser escrito com uma abordagem tecnológica muito mais simples do que os SPAs. Agora, com nomes como HTMX, essa afirmação tem ainda mais peso. O cenário do front-end é dominado pela espera de uma nova estrutura para aliviar os problemas da estrutura anterior que você estava usando. A abordagem SPA é inerentemente mais complicada do que uma abordagem hipermídia , e acumular mais tecnologia pode não ser a resposta, experimente a hipermídia.