Por que a Gumroad não escolheu o htmx

 (htmx.org)
6 pontos por GN⁺ 2024-10-04 | 1 comentários | Compartilhar no WhatsApp
  • A Gumroad avaliou o htmx no novo projeto Helper, esperando um frontend mais leve, mas mudou para React/Next.js à medida que as exigências de UX ficaram mais complexas
  • O htmx parecia promissor para interações simples, mas em formulários com validação dinâmica e campos condicionais a lógica no lado do servidor ficou verbosa, tornando o fluxo de desenvolvimento pouco natural
  • O arrastar e soltar do construtor de workflows, a colaboração em tempo real, o gerenciamento complexo de estado e a geração dinâmica de formulários foram implementados de forma mais direta no ecossistema React e no modelo de componentes
  • Havia mais material para resolver problemas e melhor suporte de ferramentas de IA no Next.js e React; o htmx ficou em desvantagem na velocidade de desenvolvimento por causa da menor quantidade de dados de aprendizado open source
  • O htmx pode ser adequado para apps com renderização no servidor já existentes ou modelos de interação simples, mas para interfaces com muito estado, como o Helper, React e Next.js se encaixaram melhor

Contexto de por que o htmx foi avaliado no Helper

  • A Gumroad começou o novo projeto Helper avaliando o htmx como candidato de frontend
  • A expectativa inicial veio da experiência anterior de que o React era pesado além do necessário, e de que o htmx poderia ser uma forma leve de adicionar interações simples
  • Dentro da equipe, também houve a avaliação de que o htmx se parecia com um meme que satiriza o ecossistema JavaScript, que ficou complexo demais
    • Assim como o Tailwind pode parecer outra sintaxe para CSS inline, havia a visão de que o htmx se aproximava mais de outra sintaxe para JavaScript inline
  • O Tailwind se consolidou no conjunto de ferramentas da Gumroad, mas o htmx não escalou de acordo com o objetivo do Helper nem levou à melhor experiência de usuário para os clientes

Onde React/Next.js pareceu mais natural

  • Experiência de desenvolvimento e tratamento de formulários

    • Embora uma implementação correta também fosse possível com htmx, a Gumroad sentiu que o processo de fazer as funcionalidades funcionarem no Next.js era mais intuitivo
    • Em formulários complexos com validação dinâmica e campos condicionais, o trabalho no lado do cliente com React era mais simples, enquanto no htmx a lógica no servidor se alongava

  • Limitações de UX e interação

    • O htmx tende a empurrar o app para um estilo Rails/CRUD, então a experiência padrão podia facilmente ficar comum ou genérica
    • A interface de arrastar e soltar do construtor de workflows exigia implementações de contorno no htmx e parecia mais rígida do que a experiência fluida obtida com bibliotecas React

  • Ferramentas de IA e velocidade para resolver problemas

    • As ferramentas de IA estavam mais familiarizadas com Next.js do que com htmx, algo atribuído à falta de dados de aprendizado open source
    • Como havia muito mais material sobre React/Next.js, a velocidade para encontrar soluções quando surgiam problemas era maior

  • Complexidade e escalabilidade

    • À medida que o projeto ficava mais complexo, a simplicidade do htmx se aproximava mais de uma limitação do que de uma vantagem
    • Com a adição de colaboração em tempo real e visualização complexa de dados, o gerenciamento de estado entre vários componentes foi ficando cada vez mais difícil na abordagem centrada no servidor do htmx

Diferenças reveladas por funcionalidade no Helper

  • Arrastar e soltar: react-beautiful-dnd no ecossistema React oferece arrastar e soltar fluido e acessível com pouca configuração
  • Gerenciamento complexo de estado: para refletir em tempo real na UI as configurações e a lógica condicional de cada etapa do workflow, abordagens de estado do React como useState ou Redux eram mais diretas
  • Geração dinâmica de formulários: criar formulários de configuração diferentes para cada tipo de etapa e alterá-los conforme a entrada do usuário foi mais intuitivo no modelo de componentes do React
  • Colaboração em tempo real: a funcionalidade para vários usuários editarem o workflow ao mesmo tempo foi implementada de forma relativamente direta com WebSockets e React, enquanto no htmx exigiria lógica mais complexa no servidor e JavaScript customizado
  • Otimização de performance: conforme o workflow crescia em tamanho e complexidade, foi possível otimizar a renderização com mais granularidade usando o virtual DOM do React e hooks como useMemo e useCallback

Ecossistema e decisão final

  • O ecossistema React/Next.js é grande e maduro, oferecendo soluções para praticamente todos os problemas que a Gumroad encontrou
  • No htmx, houve muitas situações em que era preciso fazer concessões de funcionalidade ou recriar coisas manualmente, e até na integração com serviços e bibliotecas de terceiros havia bindings para React, mas não equivalentes para htmx
  • Depois de migrar para React/Next.js, a Gumroad avaliou que foi uma escolha mais adequada para construir UX complexa
    • Foi possível avançar mais rápido, criar uma experiência de usuário mais imersiva e aproveitar ferramentas e bibliotecas já existentes
    • Também foi possível melhorar bastante a experiência do app para os clientes centrais do Helper
  • As limitações do htmx não são impossíveis de superar, mas o processo de resolvê-las acabou levando para soluções mais naturais em um ambiente centrado em JavaScript, fugindo dos pontos fortes do htmx
  • O htmx pode ser uma boa escolha para projetos com modelo de interação simples ou construídos sobre apps com renderização no servidor já existentes
  • Em interfaces complexas e com muito estado, como o Helper, React e Next.js foram mais adequados, e a Gumroad entende que pode continuar reavaliando sua stack conforme as necessidades mudem e novas tecnologias apareçam

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-04
Opiniões no Hacker News

  • Isto é algo que eu tinha comentado em outra thread: o CEO da Gumroad disse no Twitter que tinha experimentado htmx em um projeto, mas acabou escolhendo NextJS.
    Eu estava procurando um relato negativo ponderado que valesse a pena colocar no site do htmx, então perguntei se ele poderia escrever sobre a experiência, e fiquei grato por ele ter aceitado de bom grado.

    • Passei a respeitar mais o projeto justamente por essa postura de expor diretamente os pontos em que htmx pode nem sempre ser a melhor opção.
      É algo refrescante em comparação com outros projetos que afirmam ser a melhor solução para tudo.
      Fiquei especialmente curioso sobre a observação relacionada a drag and drop: será que em htmx isso é realmente visto como difícil? E, se for, há algum plano para resolver?
    • O CEO da Gumroad também disse que o próprio Rails era dívida técnica e, quando perguntaram o motivo, respondeu apenas que React era muito melhor.
      Como se Rails e React nem pudessem ser usados juntos.
      O texto em si parece menos uma experiência negativa com htmx e mais um caso em que, no momento em que aparecem drag and drop e colaboração em tempo real, a própria escolha de experimentar htmx talvez já fosse equivocada desde o início.
      Também não entendo muito bem o que o screenshot tenta mostrar, mas ainda assim acho que é um bom texto para publicar no site do htmx.
    • É respeitável mostrar os pontos em que htmx pode ser menos adequado que outras ferramentas.
      Para mim, htmx está mais para um substituto do jQuery do que para um substituto do React.
      htmx e jQuery adicionam interatividade ao documento; React tenta ser o documento inteiro.
      A ferramenta deve variar conforme o trabalho.
    • Depois de ler o texto linkado e https://htmx.org/essays/htmx-sucks/, decidi que não vou usar htmx nem recomendá-lo a outras pessoas.
    • A outra thread é https://news.ycombinator.com/item?id=41727315.

  • A parte “IA e suporte de ferramentas: também vale notar que ferramentas de IA estão muito familiarizadas com Next.js, mas não tanto com htmx” foi escrita de forma serena, como uma desvantagem, mas é um sinal bem sinistro para o futuro de ferramentas de desenvolvimento, bibliotecas, frameworks e linguagens.
    Minha previsão é que grandes modelos de linguagem vão ampliar ainda mais os efeitos de “o vencedor leva tudo” e de vantagem de pioneirismo, e também vão incentivar mais o uso de ferramentas open source graças à maior quantidade e melhor qualidade dos dados de treinamento.

    • A questão de IA e suporte de ferramentas é, na verdade, uma extensão da questão de comunidade e ecossistema.
      Mesmo antes dos grandes modelos de linguagem, React tinha a vantagem de que a maioria das perguntas já estava no StackOverflow e de que havia bibliotecas maduras para praticamente qualquer caso de uso.
      Agora, apenas surgiram pessoas que fazem a um grande modelo de linguagem as perguntas que antes fariam no StackOverflow, e o resultado é o mesmo.
      Usar o que muita gente usa traz vantagens.
    • A ideia de que grandes modelos de linguagem ampliam os efeitos de “o vencedor leva tudo” e de pioneirismo em ferramentas de desenvolvimento provavelmente é verdadeira para quem depende deles para programar.
      Mas, como estratégia de longo prazo para a carreira de engenheiro de software, acho fortemente que não é uma boa aposta.
    • Ferramentas de IA ficam presas a um determinado ponto no tempo e, mesmo treinando com materiais novos, há um limite para a quantidade de informação que elas conseguem absorver.
      Já pensei que talvez isso possa ser uma coisa boa.
      A indústria de software passa tempo demais correndo atrás das ferramentas, recursos de linguagem e frameworks mais recentes.
      Talvez um pouco de estagnação seja positivo, com mais foco em concluir o trabalho usando as ferramentas que já temos, em vez de criar um martelo novo a cada 6 meses.
    • Se um desenvolvedor não consegue trabalhar sem algo que escreva o código em seu lugar, não sei por que contratá-lo em primeiro lugar.
    • Não me preocupo muito com esse ponto, e é possível que a preocupação da Gumroad esteja exagerada.
      Só pelo comentário, não dá para saber se foi uma experiência real em que a IA não lidou bem com HTMX ou se a discussão passou para uma falta de outros materiais.
      Grandes modelos de linguagem muitas vezes funcionam muito bem como tradutores universais.
      Se eles aprendem padrões e conceitos gerais de frameworks populares e conhecem em algum grau a sintaxe de um framework menor, pela minha experiência também geram código bastante bom para frameworks de nicho.
      É parecido com o fato de piratas conseguirem falar em “linguagem de pirata” sobre assuntos que nunca foram mencionados assim nos dados de treinamento.

  • A parte “ao criar formulários complexos com validação dinâmica e campos condicionais, acabamos escrevendo lógica complexa do lado do servidor para lidar com algo que em React seria uma tarefa simples do lado do cliente” me lembra o meme de Anakin e Padmé.
    “Mas vocês também vão implementar validação no servidor, certo… certo?”

    • Se um formulário web é mais complexo do que um formulário em papel, talvez seja o caso de repensar o próprio formulário web.
      Tenho dificuldade em imaginar formulários que sejam fáceis em React e difíceis em htmx, a não ser nos casos em que se quer enfiar estado global de aplicação ao estilo React e resolver 90% com uma biblioteca.
    • A validação também é feita no servidor.
      Só que é feita uma vez no envio, não a cada página.

  • Ao contrário da frase “achei que htmx poderia ser uma boa solução para manter o frontend bem leve”, parece que htmx deixou de fazer sentido assim que eles abriram mão de um frontend leve.
    Começaram a usar bibliotecas de terceiros para renderizar UI/UX complexa e gerenciamento de estado.
    Além disso, dizer “era mais fácil fazer X em React” não é uma comparação justa se isso foi feito com uma biblioteca de terceiros.
    Você só não precisou fazer diretamente porque alguém fez por você.
    Concordo bastante com o texto, mas, se já sabiam que precisariam de estado e renderização complexos, htmx não era uma boa solução desde o início.

    • Acho que é exatamente isso.
      Gosto de htmx, mas este texto mostra que o autor tinha uma compreensão técnica bem limitada.
      Não parecem ser prós e contras que ficariam claros com um mínimo de conhecimento da plataforma web e da documentação do htmx.org; parece mais que ele quis testar HTMX pelo hype.
    • Isso forma uma boa simetria com os textos de pessoas que, em primeiro lugar, nem deveriam ter usado React e depois escrevem “troquei meu app React por htmx e tudo ficou muito melhor”.
    • O embate htmx versus JavaScript me lembra testes de desenvolvimento orientado a comportamento do behave versus testes com pytest.
      A linguagem Gherkin parece boa em casos simples e, em princípio, também pode ser estendida para casos complexos, mas quanto mais camadas de abstração você precisa gerenciar, mais conveniente se torna o pytest em Python puro.
    • Também pensei exatamente a mesma coisa.
      O escopo do projeto não era nem um pouco “simples” e, no meu caso, eu teria ido direto para React.
    • Só pela descrição das funcionalidades desejadas, parecia inevitável precisar de JavaScript pesado.

  • Sobre a parte que diz que “implementar uma interface de arrastar e soltar para o criador de workflows foi um grande desafio no htmx, exigindo soluções alternativas desajeitadas em comparação com a experiência fluida que se obtém com bibliotecas React”, o HTMX funciona melhor quando faz apenas o necessário para o bundle de frontend, e nada além disso
    Basta se conectar ao evento htmx.onLoad e, dentro do conteúdo carregado, encontrar e anexar o markup com atributos, como columns, cards, tasks etc.
    Por exemplo, dá para vincular sortable.js ao markup renderizado e conectar os eventos do sortable a atualizações de estado via HTMX
    É bem simples, e a documentação tem exatamente esse exemplo: https://htmx.org/docs/#3rd-party

    • Uso HTMX junto com componentes UIKit
      Sites modernos, com estado e dinâmicos não são nem um pouco incompatíveis com HTMX

  • Lendo o artigo, parece que a equipe é mais familiarizada com desenvolvimento frontend do que com desenvolvimento backend
    Do ponto de vista de um desenvolvedor da velha guarda, às vezes dá para perceber um pequeno receio e mal-entendidos no modo como desenvolvedores frontend pensam
    Sinceramente, acho que basta ajustar um pouco a forma de pensar para entender como essa abordagem funciona, mas também entendo que muita gente nunca viu uma abordagem cliente/servidor tradicional ao longo de toda a carreira
    Ainda assim, não dá para ignorar o valor dos componentes React prontos e a vantagem de ser fácil encontrar documentação e ajuda

    • Vejo não só os desenvolvedores, mas também os designers de UX pensarem no estilo React como uma das maiores barreiras para adotar htmx
      Uma geração de designers passou a projetar mobile e web de forma muito parecida, jogando a complexidade de implementação para os desenvolvedores
      Mas a web deve, sempre que possível, ser diferente do mobile, e tudo bem que seja
      O texto diz que o design era “generic” demais, como um app CRUD, mas isso é mesmo ruim?
      Temos a grande conquista de um modelo de documentos amplamente adotado que permite criar experiências de usuário previsíveis em todos os sites, e nós só vemos isso como “entediante”
      Tratamos o tédio como se fosse um problema intrínseco
      Entendo a pressão de mercado por experiências únicas e com marca própria que pareçam apps mobile, mas fico imaginando como seria se designers conseguissem pensar tanto no estilo WWW quanto no estilo React

  • Gosto do fato de o HTMX publicar em seu próprio site artigos como este e outros parecidos
    Parece haver vários motivos razoáveis pelos quais só HTMX não serviu bem para eles
    Não sou especialista em frontend, mas tenho algumas ideias
    Primeiro: de qualquer forma, não é preciso validar formulários também no backend?
    Fiquei curioso sobre por que foi tão difícil para o sistema backend comunicar os resultados ao frontend
    Em muitos casos há bons motivos para validar formulários tanto no frontend quanto no backend, então nesses casos só HTMX seria insuficiente, mas a forma como esse problema foi descrito é um pouco confusa
    Segundo: usar apenas HTMX pode empurrar o app um pouco nessa direção e, em alguns casos, isso é bom, mas eles parecem ter decidido que precisavam de outra abordagem para seus clientes
    Terceiro: gostaria de saber mais sobre como essa equipe estava usando ferramentas de IA para que a dependência delas se tornasse um problema importante
    Se ferramentas de desenvolvimento com IA se tornarem importantes daqui para frente, é uma questão interessante se o patamar para um novo framework ou uma nova linguagem de programação conseguir ferramentas e integrações suficientes para ser adotado ficará alto demais
    Quarto: como em uma reclamação comum sobre HTMX, alguns projetos exigem mais do que o HTMX oferece
    Quinto: uma das razões pelas quais gosto de Django e Python também é o ecossistema profundo de comunidade, integrações e add-ons
    Algo como https://unpoly.com/, que tem conceitos parecidos e mais recursos que o HTMX, talvez tivesse funcionado melhor para eles

  • Sobre a frase “o processo de desenvolvimento do Next.js pareceu natural”, não sei que parte dessa sintaxe de ReactJS é natural
    Pode ser familiar, mas natural não é
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • Pelo que sei, o HTMX não tem uma solução elegante para timers e intervalos
      No fim, provavelmente seria preciso conectar isso de forma esquisita com JavaScript
    • Esse exemplo de código é até bem generoso
      Se você quiser um hook customizado com timeout variável, pode ficar muito mais complexo
      Até o Dan teve que escrever um texto longo sobre esse tema: https://overreacted.io/making-setinterval-declarative-with-r...
    • Fico curioso para saber como seria um código que pareça natural nesse caso de uso
      Dá para escrever um exemplo?

  • É louvável que o htmx.org tenha hospedado esse artigo

    • Acho realmente valioso quando um serviço ou ferramenta explica não só por que você deve usá-lo, mas também por que não deve usá-lo
    • Publicar um texto assim é uma atitude realmente humilde e honesta
      No fim, se alguém pegar htmx e ficar irritado por ele não atender às suas necessidades, agora há um material para apontar
    • Está linkado em https://htmx.org/essays/ sob “On The Other Hand…”
    • No começo eu esperava um pouco de rant ou sarcasmo, mas na prática fiquei contente porque é um bom texto, com bons pontos
      Uso htmx em alguns dos meus projetos e tem sido muito bom
      Textos assim, por mostrarem de forma rara onde o htmx é bom e onde deixa a desejar, acabam me dando ainda mais confiança para usá-lo

  • O terceiro ponto parece assustador
    Faz imaginar um mundo em que empresas paguem para que seus frameworks sejam super-representados nos conjuntos de treinamento dos modelos e, com base nisso, vendam contratos
    É parecido com otimização para mecanismos de busca baked in dentro das ferramentas de desenvolvimento