A fadiga de gerenciar dependências: por que abandonei o React e escolhi Go+HTMX+Templ

• Este ano, depois de tocar um projeto pessoal usando Go, HTMX e Templ, decidi parar de usar React
  • No site oficial do HTMX, é possível encontrar vários argumentos convincentes para abandonar o React e escolher HTMX, mas sinto que pouca gente fala sobre a fadiga de gerenciar dependências
• O que é "fadiga de gerenciar dependências"?
  • No último projeto pessoal em que usei React (um dicionário interativo de catalão), percebi que estava gastando tempo demais principalmente atualizando dependências de pacotes React
  • Ao atualizar os pacotes para as versões mais recentes, mudanças significativas nas APIs aconteciam, e eu precisava investir tempo refatorando o código
  • Como a webapp estava implantada como serviço público em uma instância EC2, eu queria manter as dependências atualizadas
• Uma nova versão major é realmente necessária?
  • Pacotes como wouter (um pacote de roteamento para React) e TanStackQuery (usado para buscar dados do backend, fazer cache e gerenciar estado) quebraram a webapp de forma crítica por causa de atualizações major
  • Quando a primeira atualização major quebrou a aplicação, refatorei o código sem questionar, mas quando aconteceu pela segunda vez, comecei a me perguntar
  • Passei a questionar quais benefícios reais a webapp estava obtendo dessas versões major, além de correções de segurança
  • Questionei se era realmente necessário quebrar a API de componentes essenciais cinco vezes
  • Fiquei pensando quanto tempo estava perdendo que poderia ser usado para lançar novos recursos ou outros produtos
• O problema da falta de tempo
  • Como não tenho muito tempo para dedicar a projetos pessoais de programação, não quero desperdiçá-lo refatorando código depois de atualizações major de dependências
  • Se eu estivesse construindo um produto para clientes e planejasse cobrar por trabalhos futuros de manutenção, até faria sentido usar muitas dependências instáveis
  • Mas, se eu quiser criar um produto que exija manutenção mínima, eu ficaria longe do ecossistema JS
• Usando Go+HTMX+Templ
  • O principal motivo para usar Go+HTMX+Templ em projetos pessoais é que projetos em Go me permitem focar em lançar funcionalidades sem ignorar atualizações normais de dependências e segurança
  • A própria linguagem Go mantém uma biblioteca padrão estável e uma especificação de linguagem estável.

[bbulbum]

Parece que o HTMX está recebendo muitas avaliações positivas.
Fico pensando se muita gente está procurando o HTMX como uma forma de complementar aplicações baseadas em SSR.
Acho que vou tentar usar isso em um projeto paralelo.

[savvykang]

Não escolhi as bibliotecas da TanStack porque elas são mais complexas do que o necessário e, nos últimos anos, a qualidade da documentação caiu. E também fico em dúvida se realmente é preciso insistir sempre na versão mais recente, já que o ciclo de substituição dos pacotes npm é curto demais.

Mas, no trabalho da empresa, acho que não dá para abandonar o React. Em projeto pessoal, tanto faz o que você usar.

[dohyun682]

Se você simplesmente evitar atualizações de versão major, os problemas com dependências não ficam tão grandes assim...?

[aer0700]

Há pouco tempo vi um job agendado rodando internamente na empresa que ainda usava Python 2, e aquilo me deu até falta de ar.
Depois de pensar um pouco, decidi que, como está funcionando bem agora, é melhor deixar assim por enquanto. Mas não vai dar para aguentar para sempre sem atualizar, né.

[aer0700]

O cansaço de gerenciar dependências VS o tédio de reinventar a roda
É um debate antigo. Faz sentido não usar uma roda desnecessária, mas só porque não é necessária hoje, será que também não será amanhã...
Nunca usei Go, mas ultimamente tenho visto muitos servidores feitos em Go. Mesmo que eu não vá usar agora, acho que preciso ao menos experimentar uma vez.

[clickin]

Como o HTMX está meio na linha de frente das tecnologias hypadas, muita gente anda experimentando, mas fico pensando se não valeria mais a pena seguir por um caminho como go + vecty + gox.

[GN⁺]

Comentários do Hacker News

• Compartilha a experiência de abandonar bibliotecas como React e desenvolver aplicações web com Actix, Tera e HTMX. Essa stack tem ótima manutenibilidade e está ganhando popularidade entre os usuários

  • Descreve a experiência de desenvolver rapidamente uma nova aplicação web e distribuí-la para usuários de teste
  • Como não houve "fadiga de gerenciamento de dependências", foi possível obter uma compreensão mais profunda das ferramentas

• Avalia que as bibliotecas de Tanner têm muitos recursos, mas deixam a desejar no design da API

  • React Table e React Query são poderosos, mas têm fronteiras mal definidas, o que causa problemas
  • A vantagem do React é não ser um framework, parando em fronteiras bem projetadas
  • Tenta adotar apenas bibliotecas que atendam a esses critérios

• Sente que os exemplos de HTMX apenas deslocam a complexidade para outra parte, e explica que JSX é uma forma elegante de evitar templates

  • Ainda existem muitos problemas a resolver, como roteamento, gerenciamento de estado e autenticação

• Acha estranho dizer que está abandonando React, e argumenta que o problema não é o React, mas outras dependências

  • A opção de escrever o backend em Go sempre existiu

• Enfatiza que não se deve esquecer que mudanças são esperadas ao atualizar para a próxima grande versão de um pacote

  • Usa o exemplo do Remix para explicar como aplicar mudanças de forma gradual
  • Argumenta que bons pacotes exigem grande esforço

• Compartilha a experiência de migrar um projeto SPA para Django e HTMX, explicando que reduziu drasticamente a dependência de JavaScript

  • Diz que a SPA parecia uma bomba-relógio

• Argumenta que o React não é responsável por pacotes de terceiros mal mantidos

  • Explica que não são necessárias ferramentas de roteamento ou gerenciamento de estado como Redux

• Acha que o v5 do react-query deveria ter sido compatível com a API do v3, mas explica que a migração é fácil e não é obrigatória

  • Sente que a "fadiga de gerenciamento de dependências" é exagerada e aconselha manter um número razoável de dependências

• Questiona por que foi feito o upgrade de uma aplicação web que não obteve nenhum benefício adicional

  • Explica que atualizar para a versão mais recente não traz vantagens

• Explica que, após abandonar React e nextjs e migrar para outra stack, o estresse diminuiu e as atualizações já não causam mais depressão