Hotwire: tecnologia HTML over the wire

 (hotwired.dev)
2 pontos por GN⁺ 2024-06-03 | 1 comentários | Compartilhar no WhatsApp
  • Hotwire é uma abordagem para criar aplicativos web modernos enviando HTML em vez de JSON, buscando carregamento inicial rápido e boa responsividade com pouco JavaScript
  • Como a renderização permanece em templates no servidor, é possível manter um fluxo de desenvolvimento simples independentemente da linguagem usada
  • Os frameworks criados pela 37signals para o HEY se combinam para formar o ecossistema Hotwire, que vai da web a várias plataformas
  • O componente central, Turbo, lida com transições de página, envio de formulários, divisão em componentes e atualizações parciais via WebSocket sem necessidade de escrever JavaScript
  • Interações personalizadas que o Turbo não cobre são complementadas pelo Stimulus, e o Hotwire Native permite criar apps móveis nativos com base em apps web existentes

A abordagem de renderizar e enviar HTML a partir do servidor

  • Hotwire é uma abordagem alternativa para construir aplicações web modernas no estilo HTML-over-the-wire
  • Em vez de JSON, envia HTML pela rede, permitindo criar aplicações com pouco JavaScript
  • Busca carregamento rápido da primeira página, manutenção da renderização com templates no lado do servidor e uma experiência de desenvolvimento mais simples e produtiva
  • A proposta é não abrir mão da velocidade e da responsividade esperadas de aplicações tradicionais de página única
  • HTML-over-the-wire também pode servir como referência para criar suas próprias ferramentas, ou você pode usar diretamente os frameworks Hotwire que a 37signals criou para o HEY

O papel de Turbo, Stimulus e Hotwire Native

  • Turbo é o componente central do Hotwire
    • Oferece técnicas complementares para lidar rapidamente com transições de página e envios de formulários
    • Divide páginas complexas em componentes e transmite atualizações parciais da página por WebSocket
    • Entrega esses recursos sem exigir escrita de JavaScript
  • Stimulus é usado quando é necessário código personalizado que o Turbo sozinho não cobre
    • O Turbo normalmente resolve pelo menos 80% das interações que tradicionalmente exigiam JavaScript
    • O Stimulus permite lidar com estado e conexões de forma centrada em HTML
  • Hotwire Native é um framework web-first para criar aplicativos móveis nativos
    • Fornece as ferramentas necessárias para desenvolver apps móveis aproveitando um app web existente

Leituras relacionadas

1 comentários

 
GN⁺ 2024-06-03
Opiniões no Hacker News

  • Há uma versão menos divulgada desse recurso chamada htmx: https://htmx.org/
    Ela permite fazer esse tipo de coisa com um único arquivo JavaScript e, embora eu tenha visto ser usada principalmente com backends em Go, parece bastante flexível. Estou pensando em experimentar há mais ou menos um ano

    • Pelo menos pelos padrões do Hacker News, acho que htmx teve muito mais exposição
      Só no último ano foram centenas de submissões no HN 0, e houve até posts que passaram de 1000 pontos. Já Hotwire teve menos de 30 submissões no último ano 1, e a mais popular delas é este post
    • Não entendo dizer que htmx é menos divulgado. Hotwire é a primeira vez que ouço falar, mas htmx eu vejo demais por todos os lados
      Basta olhar rapidamente no YouTube para ver influenciadores de programação destacando htmx o tempo todo, com thumbnails mostrando o rosto
    • Também vale mencionar https://unpoly.com, que inclui outros recursos
    • HTMX possivelmente é mais bem divulgado do que qualquer framework
      O Twitter também é muito ativo, aparece com frequência no canal do YouTube do The Primeagen e é bem popular
    • Menos divulgado? Parece que htmx está transbordando em todas as plataformas sociais

  • Se estiver procurando algo parecido em PHP/Laravel, recomendo fortemente Livewire: https://laravel-livewire.com/
    Para projetos mais complexos, ainda uso React, mas poder escrever tudo em Blade/PHP mantendo elementos de UI reativos é sempre revigorante. Lembro de ter visto também um pacote que permite renderizar componentes React/Vue dentro do Livewire quando necessário: https://minglejs.unitedbycode.com/. Parece uma via de escape interessante quando é preciso trazer pacotes existentes

  • Antes eu era bem negativo em relação a Hotwire/Livewire, mas hoje os vejo como ferramentas adequadas dependendo do contexto
    Enviar templates parciais pela rede é uma abordagem de hipermídia; é só que hoje em dia não criamos muito bem apps de hipermídia. Releli o artigo de REST do RTF junto com htmx e cheguei até aqui; não acho que hipermídia seja uma arquitetura intrinsecamente superior, mas ela é uma alternativa legítima entre várias, e é bom que continue evoluindo, ainda que lentamente

  • É provavelmente uma das formas mais fáceis de criar uma PWA sem cair no buraco sem fim de React/Vue/Svelte
    Já usei esses também e acho ótimos, mas, comparados ao htmx, parecem mais centrados na experiência do desenvolvedor do que na tecnologia. A competição entre eles provavelmente vai depender, no fim, de qual se integra melhor a cada framework de backend

    • Se o app móvel for simplesmente um WebView, talvez. Caso contrário, será preciso manter tanto uma API REST para o app móvel quanto handlers de requisições Hotwire/Livewire que entregam fragmentos de HTML
      Pessoalmente, vejo PWA como um problema do cliente, e acho que deve ser tratado no lado do cliente, sem adicionar dependências ao servidor
    • Fico curioso para saber por que essa abordagem seria menos um buraco sem fim do que as alternativas mencionadas

  • A conversa no HN de 2020, mais próxima da época em que isso apareceu pela primeira vez, está aqui: https://news.ycombinator.com/item?id=25507942

  • Dá a sensação de que quase demos uma volta completa. Lembro que, por volta de 2005 ou 2006, usávamos uma abordagem de interceptar cliques, anexar parâmetros e receber apenas fragmentos parciais de HTML renderizados, substituindo o corpo com .innerHTML

    • Antes do AJAX surgir no início dos anos 2000, Adam Rifkin mostrou uma demo da startup dele, a KnowNow, e na época era chocante ver uma página web se atualizar sozinha sem recarregar
      O truque era manter uma requisição HTTP aberta continuamente e o servidor enviar atualizações de vez em quando; essas atualizações também eram HTML. Na época talvez nem desse para manipular o DOM, então podia ser literalmente uma página com uma tag que nunca fechava
    • Mais do que dizer que demos uma volta completa, é mais correto ver isso como diferentes paradigmas de UI web ampliando seu alcance
      Frameworks de renderização no servidor estão facilitando interações no cliente, e o React, por meio de RSC, está facilitando a renderização no servidor. Se for uma web app com altíssima interatividade, uma SPA ainda leva vantagem
    • Sempre ouço esse tipo de comentário quando Hotwire ou bibliotecas parecidas aparecem, mas, na prática, CRUD simples baseado em AJAX nunca desapareceu
      Existem muitíssimos projetos SPA, mas isso não descreve todos os sites do mundo
    • Em https://animasci.com/ usam uma abordagem parecida
      A paginação foi implementada assim: ao rolar a página e clicar em “Show more”, a próxima página é solicitada ao servidor como um fragmento de HTML, carregada em um iframe invisível e, quando o carregamento termina, anexada à página atual
    • No fim dos anos 2000 eu gostava bastante do Wicket e não gostava de JavaScript, mas gerenciar estado de UI e templates no servidor facilmente virava uma armadilha de desempenho e escalabilidade em ambientes de equipe
      Considerando o quanto a web, JavaScript e TypeScript melhoraram nesse meio-tempo, é difícil me empolgar de novo com essa abordagem

  • Não trabalhei muito com web apps que exigem frontends altamente interativos, mas, em lojas de e-commerce e apps Rails internos, Turbo e Stimulus reduziram muito o volume de coisas que novos desenvolvedores precisavam aprender

    • Mantendo a stack simples, isso nunca foi tão difícil assim
      Por exemplo, em um projeto Django, criamos rapidamente uma ferramenta interna completa com o confiável KnockoutJS, e isso tem certa afinidade com o espírito do HTMX. O ainda inicial Arrow.JS é parecido. A complexidade, especialmente a complexidade de UI, em geral foi algo que nós mesmos criamos; as formas antigas não estão nada obsoletas e, na verdade, estão voltando. Há uma geração de desenvolvedores jovens que entrou no setor na época mais tola, quando a indústria tentava convencer todo mundo de que toda aplicação web precisava virar um bloco excessivamente complexo e difícil de suportar
    • Como alguém que já usou Stimulus, Stimulus era péssimo e eu não vou usar de novo. Hotwire era aceitável

  • Uso o Hey pagando desde o lançamento, e, se a experiência da web app do Hey for o melhor exemplo de Hotwire, prefiro passar
    Em conexões lentas, é ruim. Pode ser porque os desenvolvedores não colocaram estados de carregamento ou erro, pode ser pela alta complexidade, ou pode ser um bug do Hey. Não sei, mas não é bom
    Com latência média a alta, o comportamento parece imprevisível ou bugado. Caixas sem conteúdo abrem, links não se comportam como esperado e, quando várias ações são feitas rapidamente em sequência, elas não são interrompidas de um jeito intuitivo. Simplesmente parece desencontrado
    Por pior que SPAs sejam, isso parece um passo para longe de uma UI que pareça nativa e natural

  • O motivo de este artigo ter voltado a aparecer agora é que, na semana passada, alguém postou que o Hey demora para abrir um modal: https://x.com/noahflk/status/1795758603577545035
    O Hey foi criado por DHH, e DHH também criou Hotwire e Rails. Depois disso, virou uma discussão acalorada, misturando a resposta de DHH de que o vídeo original foi gravado em uma rede limitada, reações dizendo que, se carregar um modal leva tempo, o Hotwire depende demais da rede, defesas de Rails/Hotwire e críticas à abordagem. Foi um grande assunto no Twitter na semana passada

    • É verdade que DHH disse que o vídeo original foi gravado em uma rede limitada
      O autor também escreveu que foi “deliberadamente deixado lento para demonstração”: https://x.com/noahflk/status/1795855075526471915. Ele disse que não queria mostrar a experiência de alguém com “um bom MacBook em SF e internet gigabit”, mas falar de alguém usando internet móvel lenta e um notebook barato. Também houve quem apontasse que a SPA do Google Calendar é muito mais lenta, e as únicas opções também não são “internet gigabit em SF” e “3G fortemente limitado”. A postagem original era muito enganosa e, na prática, quase uma mentira
    • Link da resposta direta de DHH: https://x.com/dhh/status/1796163806650868149
    • Quando vi o Hey cerca de um ano atrás, ele parecia bem ágil mesmo do outro lado do Pacífico
      A estrutura da página, em especial, me impressionou. Por exemplo, no overlay de menu de contexto, eles aplicavam a combinação details/summary/anchor como aprimoramento progressivo, e, mesmo com JavaScript desativado ou com assets não carregados, o conteúdo do menu era carregado elegantemente em um layout simples. Também havia muitos outros usos cuidadosos de Web APIs, e lembro que o código do cliente quase não era ofuscado e vinha com source maps. Não sou fã do DHH nem pretendo acompanhar o drama daquela semana, mas, desta vez, senti que a 37signals fez direito
    • Já foi corrigido. A atualização pode ser conferida aqui: https://x.com/dhh/status/1797370923391357143

  • Há 2 anos criei o Swap JS, uma implementação mais minimalista da mesma ideia: https://github.com/josephernest/Swap
    Usei em alguns projetos e funciona bem