LiveView, a tecnologia que combina melhor com Svelte

A combinação de LiveView e Svelte

• LiveView oferece uma maneira única de construir aplicações web.
• O servidor mantém o estado, processa o comportamento do frontend no backend e atualiza o DOM de forma incremental.
• A complexidade dos SPAs vem da complexidade dos sistemas distribuídos, e o LiveView oferece uma experiência rica no cliente sem microsserviços de frontend.

As dificuldades do LiveView

• O estado no lado do cliente é inevitável, e a latência entre servidor e usuário não pode ser evitada.
• O LiveView cuida de muitas mudanças no DOM no servidor, mas não consegue controlar tudo.
• O LiveView tem três tipos de componentes: LiveViews, LiveComponents e Components.
• Refatorar entre LiveView e LiveComponents é mais trabalhoso do que parece.

A direção ambígua do LiveView

• O LiveView frequentemente dá a sensação de que está faltando alguma coisa.
• O LiveView tem muito em comum com frameworks modernos de frontend, mas é preciso reconhecer as diferenças e abordar os problemas de outra forma.

LiveView + Svelte

• LiveSvelte permite renderizar componentes Svelte dentro do LiveView.
• O backend controla as props dos componentes de frontend, e tanto frontend quanto backend mantêm estado.
• Existe um canal de comunicação privado e bidirecional entre frontend e backend.

As características inovadoras do LiveSvelte

• A divisão de responsabilidades entre backend e frontend é clara, e a complexidade fica concentrada no lado do servidor.
• O LiveView brilha mais como frontend para o backend, fornecendo um processo de backend que renderiza componentes de frontend e mantém o estado.

A opinião do GN⁺

• A combinação de LiveView e Svelte separa de forma eficiente o gerenciamento de estado entre servidor e cliente, permitindo que desenvolvedores criem aplicações de forma mais rápida e intuitiva.
• Essa tecnologia pode ser especialmente útil para aplicações web em que a interação em tempo real é importante, contribuindo para melhorar a experiência do usuário.
• No entanto, como a latência com o servidor pode afetar a experiência do usuário, otimização de desempenho e posicionamento regional dos servidores podem ser fatores importantes.
• A combinação de LiveView e Svelte apresenta um novo paradigma para desenvolvedores acostumados ao modelo tradicional de desenvolvimento SPA, com potencial para reduzir a curva de aprendizado e aumentar a eficiência no desenvolvimento.
• A sincronização de estado em tempo real e a comunicação bidirecional oferecidas por essa tecnologia podem torná-la uma escolha atraente especialmente para ferramentas colaborativas, dashboards ou aplicações que lidam com dados em tempo real.

[GN⁺]

Opiniões no Hacker News

• Um dos padrões usados em videogames multiplayer é ter código que roda essencialmente tanto no cliente quanto no servidor.

  • O código do cliente roda como uma previsão do estado do servidor.
  • Quando o estado do servidor é recebido, ele é aplicado à força ao estado do cliente.
  • Em jogos, "previsão" é um termo apropriado: o cliente consegue adivinhar bem o resultado das próprias entradas, mas não pode ter certeza porque não conhece as entradas dos outros jogadores.
  • Esse paradigma também pode ser usado para reagir imediatamente à entrada do cliente enquanto se espera pelo estado autoritativo do servidor, por exemplo, ativar/desativar um dropdown ou exibir um spinner de carregamento.
  • Também há muito estado no cliente que não roda no servidor, como sistemas de partículas e ragdoll — coisas que não precisam ser exatamente iguais em todos os clientes e não interagem com entradas de outros jogadores/física.

• Fiz uma apresentação na ElixirConf 2022 sobre como combinar LiveView e Svelte, e os contribuidores do live_svelte ajudaram a tornar isso realidade.

  • Estado no lado do cliente sempre é necessário, especialmente em apps com UX rica.
  • Em Nova York, especialmente em movimento, a conexão de rede não é garantida.
  • A capacidade de usar o pubsub do Phoenix para enviar reativamente ao cliente mudanças de estado do servidor ocorridas em outros servidores é muito poderosa.

• Quando novas linhas entram, o LiveView atualiza o cliente, então basta fazer push delas para a tabela.

  • Eu recomendaria não usar isso em apps de negócios com linhas interativas.
  • Pode haver atraso cognitivo, fazendo o usuário clicar na coisa errada, enviar um e-mail para o cliente errado ou estornar a transação errada.
  • Um bom UX é usar um banner discreto avisando que os dados mudaram ou, em casos urgentes, apenas adicionar novas linhas sem mudar a posição de rolagem.

• Usamos Svelte e LiveView juntos no BeaconCMS.

  • Há bons casos de uso quando você quer controle mais refinado da UI no cliente.
  • Mesmo usando Phoenix, nem sempre LiveView é a resposta; às vezes uma página renderizada estaticamente é perfeitamente adequada.
  • Eu aconselharia não adotar uma abordagem de tudo ou nada para tudo.
  • Como o artigo aponta, há alguns bons casos de uso para sair do 'jeito LiveView'.
  • Se houver um round trip de 1000ms, pode haver outras considerações, mas servidores geograficamente distribuídos podem não ser viáveis por custo etc., então adicionar gerenciamento de estado no cliente pode ser a solução.

• Em vez de gerenciar estado no cliente, você gerencia estado tanto no cliente quanto no servidor.

  • É difícil ver isso como uma melhoria; embora elimine a necessidade de construir outra API, isso não significa necessariamente que seja melhor.

• A limitação dessa abordagem está na velocidade da luz: há um limite para o quão perto o servidor pode ficar do usuário.

  • O próximo passo é compilar o servidor para WebAssembly e enviá-lo ao cliente para renderizar respostas de forma otimista até que o servidor real retorne.
  • Pode soar meio maluco, mas já fiz isso com sucesso em um projeto real, e a experiência é quase mágica.

• Sou a pessoa que criou o LiveSvelte, então fiquem à vontade para perguntar.

• De forma geral, eu queria construir apps com este modelo: orientados a eventos, com atualizações bidirecionais em tempo real e servidor, eventos ordenados, estado local e remoto...

  • Eu não conhecia LiveView e nunca tinha usado linguagens da família Erlang, mas claramente eles descobriram algo.
  • O modelo tradicional de requisição-resposta causa muitos problemas de consistência e dados desatualizados.
  • Um pensamento esperançoso, mas talvez controverso: se os últimos 10 anos foram sobre integrar conceitos de FP às linguagens mainstream, espero que os próximos 10 sejam sobre integrar programação orientada a mensagens com estado (reativa?) ao full stack mainstream.

• Estou usando controladores Stimulus reutilizáveis junto com LiveView no app, e isso também funciona sem atritos.

  • No geral, construir com LiveView é prazeroso, mas quanto mais você o usa em cenários reais, mais percebe as vantagens de frameworks HTTP sem estado.
  • Frameworks como Hotwire oferecem melhor desempenho e mais resiliência a reconexões, além de evitar a necessidade de colocar servidores mais perto do usuário.

• Projeto muito legal! Acabei de publicar um episódio do Svelte Radio sobre isso.