Bom dia mano, ótimo artigo!
Trampo com Vue e confesso que as vezes, aqui no nosso SPA existe uma certa "overdose" de maneiras e maneiras de inserir animações nos componentes, tudo isso claro é código legado, já existia antes de eu chegar, mas mesmo assim é interessante saber que coisas como a View Transitions, uma vez que vingue e seja usada com boas práticas, podem simplificar a vida do frontend daqui pra frente.
Eu acho que dos problemas que as tecnologias modernas resolvem vão muito além de só transições mais bonitinhas.
Se esse fosse mesmo o carro-chefe, já teriam morrido quando começaram com essa história de SSR.
No meu ver a criação de componentes, código mais declarativo, e reatividade que são o Core do desenvolvimento moderno.
Então até lançarem Signals ou algo do gênero de forma nativa, e melhorarem os Web Components dificilmente vão "matar" essa nova leva de frameworks.
No meu ver, a ViewTransition API é muito mais uma feature a ser absorvida por eles do que uma forma de substituir.
Mesmo com HTMX você não se livra do estado no client-side, aplicações que não isso e só fazem as coisas baseadas em AJAX, já não precisariam muito desses frameworks em primeiro lugar, então ele não resolve bem o mesmo problema dos frameworks modernos, e sim um problema tangencial. As pessoas continuam utilizando eles, ou por erro num overengeneering, ou pelos benefícios do modelo de componentes para a organização do código, que tendem a serem melhores que as soluções oferecidas por template engines no back-end. Logo, ViewTransitions não seria a solução para isso, e sim os Web Components
Obrigado pelo comentário, traz uma discussão interessante. Embora não concorde com muito do que diz, consigo entender e apreciar sua visão, você infezlimente provavelmente está certo ao afirmar que esta nova API provalvemente vai ser absorvida pelo mesmo jeito 'burro' de fazer as coisas do que ser usada para criar um 'jeito' melhor.
Quando menciona "transições bonitinhas" esta se referindo à própia "reatividade" que cita como um dos pilares do desenvolvimento web moderno. É a capacidade do navegador de responder a mudanças no estado de forma fluida e eficiente. O browser é reativo por natureza, pois tudo é baseado em eventos em sua API. No entanto, sem as transições adequadas, essa reatividade não é aparente.
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.
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.
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.