Eu não considero aplicações voltadas ao servidor como "jeito" melhor. Acredito que o melhor caminho mesmo continua sendo o híbrido que nós atingimos com o passo do SSR.

Quando eu digo reatividade, é sim algo diferente das ViewTransitions, Reatividade não tem muito a ver com animações (inclusive o React é péssimo nisso por conta do modelo imutável dele).

Reatividade é simplesmente a capacidade de refletir alterações no estado da aplicação na UI. Você poder declarar uma variável que quando você atualizar, os pontos da tela que usam ela, atualizem também.

E isso é algo essencial para se escrever a UI de forma declarativa.

Eu até posso conceder que existem coisas reativas no navegador (ex: innerHTML), mas você não deveria depender dessas partes para gerenciar o estado da sua aplicação, pois elas estão acopladas a objetos da camada de View, e nós já temos um bom histórico para saber que misturar camada de dados com camada de apresentação não é uma boa ideia.

Por isso que o ideal era ter algo como signals para ser possível ter uma separação mais clara entre as duas camadas.

Se eu fosse apostar numa alternativa server side, seria algo como o Livewire do Laravel no lugar do HTMX. Isso sim é uma solução que atua no server side (o que possibilitaria bundles mais leves no front-end) com as vantagens dos frameworks de front-end.

O HTMX me parece uma tailwindização do JS no HTML. E nesse sentido eu acho coisas como o Alpine ou o próprio Vue muito melhores. Porém eu vejo um mérito que se ele fosse integrado ao Vue de alguma forma por meio de diretivas customizadas, nós teriamos realmente uma solução muito superior.

clacerdaano passado

Um jeito melhor é simplemente remover qualquer estado que se refere a logica de apresentação. Claro aplicações complexas ainda vão ter precisar gerenciar o estado para outras tarefas, mas simplemente não deveria existir qualquer estado de uma aplicação associado apenas a sua apresentação. O estado é proprio documento html, muito simples. Concordo que a View API não resolve o problema de escrever uma UI declaritiva, mas pode elimnar o problema dos estados da UI por completo.

Particurlamente também não gosto da forma que HTMX é utilizado, acredito que mais mistura lógica e apresentação do que outras abordagens, mas defendo e concordo com sua filosofia central.

LucasAyabeano passado
Estado na apresentação é sim necessário, tipo, é todo o ponto de existir JavaScript. O que é desnecessário na maior parte das vezes é o estado inteiro da aplicação (que é o que vc acaba gravando no banco de dados), provavelmente é isso que você está se referindo, que até onde eu entendi lendo a doc, tbm é o ponto do HTMX, e nisso eu tbm concordo. Você precisa disso para escrever os componentes, por exemplo você vai e escreve uma validação de formulário, você precisa de estado para fazer conseguir atualizar as classes dos campos. Outro exemplo é um modal (eu sei que agr tem tag de modal e a popover api) vc precisa de estado para manter o estado de aberto/fechado Uma coisa que eu sempre preciso de estado para lidar é um input que simboliza uma lista, e ai você vai adicionando novos campos, manter estado no back-end para isso é algo que seria um desperdício de internet. Até a pessoa terminar de criar/editar os itens, é um estado que deveria ser totalmente local. Você só precisa de estado no back-end para salvar as modificações da lista. Em Data Tables com filtros também é algo bem útil (nem que seja só para saber quais filtros foram selecionados). Então sim, estado é importante no front-end tbm, ele não serve só para coisas que vc lidaria com AJAX (o que sim tem como eliminar e eu concordo com vc nesse ponto), mas sim para estados locais de alguns componentes se não tiver isso não rola a interatividade dos componentes, a gente ia ficar dependente de os caras nos darem novas tags que fazem o que a gente precisa.