3 min de leitura ·

View Transitions API: O Fim do Desenvolvimento Web Moderno?

O cenário do desenvolvimento web tem sido marcado por constantes evoluções. Atualmente frameworks e bibliotecas JavaScript dominam o espaço, buscando oferecer experiências de usuário mais dinâmicas e interativas. No entanto, a emergente View Transitions API pode estar prestes a redefinir o panorama do desenvolvimento web. Vamos explorar como.

Desafios do Desenvolvimento Web Atual:

Historicamente, criar transições fluidas entre diferentes estados de uma aplicação web tem sido uma tarefa árdua. Um dos principais fatores que levou a rápida adoção do conceito de single page aplications foi a possibilidade de se livrar dos 'repugnantes' recarregamentos da página inteira.

Ainda assim, esse novo paradigma exige dos dos desenvolvedores uma intrincada combinação de CSS e JavaScript, muitas vezes levando a uma gestão de estado complexa e manipulação intensiva do DOM, o que explica a depêdencia massiva de frameworks e bibliotecas para este propósito.

Criou-se a demanda por uma experiência do usuário rica, e a necessidade de adotar APIs sem qualquer estado no servidor e implementar lógicas complexas em JavaScript para lidar com toda a apresentação e interação com o usuário.

A Promessa da View Transitions API:

A View Transitions API surge como uma luz no fim do túnel. Seu principal objetivo é simplificar o processo de criação de transições animadas entre diferentes estados do DOM. Isso significa que os desenvolvedores podem criar transições suaves com menos código e menos complexidade.

Embora a View Transitions API simplifique as transições, ela não substitui diretamente a gestão de estado. No entanto, se combinarmos essa API com uma abordagem mais orientada ao servidor, onde a lógica é predominantemente tratada no servidor e o cliente se concentra apenas na renderização, a necessidade de gestão de estado no lado do cliente pode ser significativamente reduzida e virtualmente eliminada mantendo-se o mesmo nível de interatividade que fomos acostumados.

O Futuro dos Frameworks Modernos:

Assim como a API DOM nativa 'matou'o jQuery, a View Transitions API tem o potencial de influenciar o cenário do desenvolvimento web. Se adotada em larga escala, pode-se imaginar um futuro onde frameworks frontend se tornem pouco dominantes, dando lugar a soluções mais leves e eficientes. O HTMX por exemplo tem ganhado bastante relevancia e notoriedade recentemente e é uma solução que minimiza a necessidade de JavaScript e promove uma abordagem orientada ao servidor. A View API que pode potenciamente criar um modelo padrozinado para esta nova abordagem de desenvolvimento.

Conclusão:

A View Transitions API representa mais do que apenas uma nova ferramenta; ela simboliza uma possível mudança de paradigma no desenvolvimento web. Com a combinação de arquiteturas orientadas ao servidor o futuro do desenvolvimento web pode ser mais simplificado, eficiente e centrado no usuário. A era das aplicações web pesadas e complexas pode estar chegando ao fim, abrindo caminho para uma nova era de simplicidade e eficiência.

ThomasAlmeida

1 ano atrás

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.

LucasAyabe

1 ano atrás

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

clacerda

Autor

1 ano atrás

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.

LucasAyabe

1 ano atrás

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.

clacerda

Autor

1 ano atrás

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.

LucasAyabe

1 ano atrás

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.