Show HN: Playground de HTMX implementado 100% no navegador

 (lassebomh.github.io)
6 pontos por GN⁺ 2024-01-09 | 1 comentários | Compartilhar no WhatsApp
  • É um sandbox de código que permite começar a experimentar HTMX dentro do navegador imediatamente, sem instalação nem configuração local
  • Em server.js, ele lida com endpoints e renderização de templates, e as requisições HTMX são interceptadas por um servidor simulado dentro do navegador
  • O processamento de requisições e o estilo de templates são familiares para usuários de Django, e também pode ser usado para experimentar bibliotecas além do HTMX
  • O compartilhamento é feito exportando com “Copy as JSON” e depois inserindo a URL raw do Gist em “Load Playground”
  • É preciso ficar atento à ausência de navegação entre páginas, ao suporte limitado a dispositivos móveis e à perda de atualizações de estado em on.get("/") causada pelo carregamento inicial do iframe

Sandbox de HTMX executado dentro do navegador

  • O HTMX Playground é um sandbox de código simples para experimentar HTMX sem instalação
  • Ele oferece exemplos adaptados dos exemplos originais do htmx.org
  • É possível escrever código dentro do navegador em um fluxo parecido com o de um backend
    • Define endpoints em server.js
    • Pode renderizar templates diretamente
    • Um servidor simulado intercepta as requisições que saem do HTMX
  • O processamento de requisições e o template engine têm um formato familiar para usuários de Django
  • O projeto em si não se limita apenas ao HTMX, então também é possível testar outras bibliotecas
  • O código está disponível no GitHub

Forma de salvar e compartilhar, e limitações conhecidas

  • Salvar e compartilhar

    • Clique em “Copy as JSON” no canto superior direito para copiar o conteúdo
    • Envie o conteúdo copiado para um Gist
    • Insira a URL raw em “Load Playground”
    • Quando a URL da página for atualizada, ela poderá ser compartilhada

  • Limitações

    • Não há navegação entre páginas
    • O suporte a dispositivos móveis é limitado
    • server.js pode manter estado, como no exemplo Click to Edit
    • Se o estado for atualizado na view on.get("/"), essa atualização pode desaparecer
      • Isso acontece porque o carregamento inicial da página é buscado primeiro em um iframe separado antes de atualizar o iframe na tela

  • Bibliotecas usadas

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-09
Opiniões no Hacker News

  • Sou a pessoa que criou o htmx, e fico muito grato por terem feito isso; achei muito bacana

    • Fico curioso se existe uma forma de usar HTMX com o mínimo de mudanças no lado do servidor
      Em uma página existente, ao preencher e enviar um formulário, a resposta vem como uma página inteira; se fosse possível dizer ao htmx “vai voltar uma página inteira, mas atualize apenas #my-form”, talvez não fosse preciso colocar no servidor uma ramificação do tipo “se for uma requisição htmx”
      Isso seria bom para quem quer que o site funcione mesmo sem JavaScript, e também permitiria tratar vários recursos, como comentários, assinatura de e-mail e botões de curtir, com um único endpoint de backend
    • Fico curioso se você já ouviu falar do Phoenix LiveView e se é um conceito parecido com htmx

  • Pensei em usar HTMX seriamente, mas me preocupo que o pool de desenvolvedores seja pequeno demais e dificulte contratações
    Eu estava acostumado a frameworks proprietários parecidos com Thymeleaf, como o isml da Intershop, e recentemente pensava em migrar para uma stack de frontend com Angular, porque é mais fácil contratar desenvolvedores frontend dedicados
    Abordagens como htmx podem ficar complexas, os desenvolvedores não querem lutar contra monstros de espaguete, e, se o frontend só produzir HTML e o backend tiver que juntar tudo, os desenvolvedores backend podem virar o gargalo
    Fico curioso se o HTMX levou essas armadilhas em consideração e como lida com elas

    • htmx é muito intuitivo de aprender; se não for alguém saído de um bootcamp de programação que só aprendeu React, acho que um desenvolvedor que conheça tópicos reais de ciência da computação consegue trabalhar produtivamente em no máximo uma semana
    • A resposta é simples: HTMX leva menos de meio dia para aprender, e provavelmente bem menos que isso
      Dito isso, HTMX não resolve todas as situações; às vezes é preciso uma aplicação de página única usando um framework JavaScript
    • É interessante mencionar Angular e depois dizer que htmx pode ficar complexo; parece haver uma diferença de perspectiva sobre complexidade
      Frameworks como Angular dão estrutura, mas a complexidade continua lá, e talvez seja muito maior
      No fim, o que se precisa é de um desenvolvedor frontend que conheça bem a stack web, como JavaScript, CSS, HTML e APIs do navegador; essa pessoa consegue escolher as ferramentas e frameworks adequados ao trabalho e aprende algo como HTMX rapidamente
    • Nada é tão persuasivo quanto sucesso, e o htmx ficou em 2º lugar na categoria de frameworks do JS Rising Stars de 2023
      https://risingstars.js.org/2023/en#section-framework
      Ficou logo atrás do React e à frente de Vue, Svelte e Angular, então, nesse ponto, o futuro parece bom. Ainda assim, espero que o ranking caia quando o entusiasmo inicial diminuir
      htmx é bastante simples, então a maioria dos desenvolvedores web consegue aprendê-lo em cerca de um dia, mas o modo de desenvolvimento empurra a organização para um paradigma full-stack em que o desenvolvedor é dono da funcionalidade inteira, então não só desenvolvedores, mas também PMs e arquitetos precisam mudar sua forma de pensar
      Também há um livro online gratuito: https://hypermedia.systems
      Além da documentação (https://htmx.org/docs, cerca de uma hora de leitura), há textos que tratam de questões filosóficas e práticas sobre htmx e hipermídia em geral: https://htmx.org/essays
      htmx tem pouquíssimas ideias básicas e procura ser “extensível”, permitindo implementar comportamentos úteis como lazy loading com apenas dois atributos: https://htmx.org/examples/lazy-load
      Ao mesmo tempo, também há hooks, como eventos e filtros de eventos, além de recursos mais profundos; se você se aprofundar, consegue implementar o comportamento desejado
      Código espaguete é um risco constante em todo desenvolvimento de software, e eu pessoalmente nunca me convenci de que bibliotecas de aplicações de página única impeçam espaguete
      Com htmx, é melhor concentrar o esforço no backend e decompor bem a aplicação usando as ferramentas que o ambiente do lado do servidor oferece
      Como o htmx permite escolher qualquer tecnologia de servidor, ele oferece mais opções e paradigmas para organizar a lógica da aplicação do que aplicações de página única que já têm um grande app JavaScript/TypeScript no frontend e acabam empurrando o backend nessa direção também
      Também tentei organizar aqui em que tipo de aplicação o htmx é uma boa escolha: https://htmx.org/essays/when-to-use-hypermedia/
      htmx é uma boa ferramenta em muitos casos, mas é só uma ferramenta; não é uma solução universal para desenvolvimento web
    • Contratar é mais parecido com avaliar competência de backend do que histórico com HTMX
      É como contratar um desenvolvedor backend que consegue fazer um pouco de frontend; não precisa ter HTMX no currículo, basta ter fundamentos como JavaScript
      A maioria dos desenvolvedores web atende a esse requisito

  • Tenho usado MapLibre com Django e htmx, e acho que deveria publicar exemplos para poder compartilhar com outras pessoas

    • Eu também fiz algo parecido em https://ratethispad.com, e o processo de criação foi bem divertido
      Ninguém usa, mas eu também gostaria de ver esse projeto
    • Não tenho nada que possa compartilhar publicamente, mas venho trabalhando com Django, htmx, SQLAlchemy, Plotly e achei bastante sólido
    • Se quiser portar mais exemplos oficiais, crie uma issue com o link e posso adicioná-los ao repositório

  • Pelo que sei, por design, o Monaco não funciona em dispositivos móveis, então no mobile usam o Ace
    Pelo menos era assim na última vez que verifiquei as issues do GitHub
    [0] https://github.com/Microsoft/monaco-editor/issues/246

  • Isso também suporta ActiveX?

    • É triste perceber que tenho idade suficiente para entender essa piada
    • Me lembrou do HP Quality Center
      Nas versões iniciais, a UI inteira era em ActiveX, e lembro de ver um monte de barras de progresso instalando DLLs

  • Também dá para criar algo assim usando Service Worker e permitir navegar abrindo várias páginas em outras abas
    Acho que não seria tão difícil, e a geração das páginas poderia usar JavaScript puro ou o que o usuário quisesse

  • Foi feito em Svelte; cadê os puristas de MPA e os forcados?

    • Sou purista de MPA, mas reconheço plenamente que há uma categoria de aplicações em que um app de página única é a melhor opção

  • Gostei do conceito do htmx e comecei a ler o livro hoje, mas toda vez que penso que um dia também vou ter que dar suporte a apps móveis nativos, fico hesitante em usá-lo
    Nesse caso, acho que teria que reescrever não só o frontend, mas também uma boa parte do backend
    Conheço o hyperview.org, mas para os casos de uso que me interessam, um app em React Native não é suficiente

  • Fico curioso se há alguém criando apps offline com um servidor virtual definido dentro de um Service Worker e um modelo de requisição-resposta em HTML/HTMX

    • Boa pergunta
      Gosto de htmx, mas não consegui usá-lo em situações em que precisava funcionar offline
      Se fosse possível executar o código do servidor diretamente no worker, seria um hack excelente
    • Estou criando um servidor/backend para htmx que roda como um serviço local ao lado do navegador
      Em tese, qualquer stack de servidor que possa ser auto-hospedada serviria
      O objetivo é criar um binário único sem dependência de serviços externos, e estou usando Go
      Muitos componentes, como serviço local com autoatualização e banco de dados replicado, já estão bem encaminhados, e também é fácil fazer compilação cruzada para vários sistemas operacionais e arquiteturas
      Como alternativa a colocar tudo no navegador, essa abordagem parece bastante razoável, desde que seja possível executar um processo separado
      Só seria bom se Go tivesse um gerenciamento de permissões como o do Deno
    • Há um exemplo real: https://github.com/jon49/htmx-todomvc
      Uso esse padrão em todos os meus apps pessoais, só que com uma pequena biblioteca estilo htmx que eu mesmo fiz
      Acho que mudar para HTMX também não seria tão difícil

  • Fico imaginando se levar HATEOAS para apps desktop ou móveis seria uma boa ideia, e poderia ser um experimento interessante

    • Se você está falando de mobile nativo, por volta de 2013 usei HATEOAS em código nativo
      Funciona bem, mas não é tão flexível quanto na web, e cada tela linkável precisa ser desenvolvida de forma rigorosamente caixa-preta
      A tentativa em si foi interessante, mas não tenho certeza de quanto vale a pena usar em produção
    • Sempre vi HATEOAS apenas como um conceito abstrato, e nunca senti, em uma UI real, que “a interação do usuário realmente melhorou”
      REST foi bem-vindo por simplificar os monstros do SOAP, mas também trouxe bastante dogmatismo
      Entendo o propósito fundamental do REST, porque ele alinha conceitos, dados e arquitetura de serviços de forma natural para o usuário
      Mas HATEOAS me pareceu mais o resultado de querer mais dogmatismo e pose em reuniões de arquitetura, em vez de focar se a experiência do usuário melhora graças ao modelo
      Fico curioso se existe algum exemplo de UI que mostre por que HATEOAS deveria ser adotado como princípio básico
      Basicamente, cada página tem links para “o que fazer a seguir”, e HATEOAS parece uma forma chamativa de levar esse modelo de estado para chamadas de serviços REST
    • Primeiro eu me pergunto se HATEOAS é uma boa ideia
    • Está aqui: https://hyperview.org/