- htmx foi selecionado para o primeiro GitHub Open Source Accelerator, ganhando a oportunidade de colaborar com projetos open source maduros e aprender com eles
- A participação serve como uma oportunidade para apresentar hypermedia e a abordagem do htmx a uma comunidade de desenvolvedores mais ampla
- O htmx pretende usar o período do Accelerator para começar a trabalhar no htmx 2.0
- Para manter e continuar desenvolvendo o projeto, aprender como transformar o trabalho no htmx em um emprego em tempo integral também continua sendo uma tarefa importante
- Os projetos selecionados em conjunto abrangem diversas áreas de open source, como segurança, documentação, autenticação, notificações e CMS, mostrando o alcance do GitHub Accelerator
A oportunidade para o htmx
- O htmx foi selecionado para a primeira turma do GitHub Open Source Accelerator
- Com essa seleção, ele poderá aprender com desenvolvedores e projetos open source bem-sucedidos e colaborar com eles
- O htmx vê esse processo como uma forma de divulgar hypermedia e o htmx de maneira mais ampla
- Há dois objetivos principais durante a participação no Accelerator
- Iniciar o trabalho no htmx 2.0
- Aprender como transformar o trabalho no htmx em um emprego em tempo integral
Projetos open source selecionados junto com ele
- BoxyHQ: suíte de APIs para segurança e privacidade, ajudando equipes de engenharia a criar e implantar aplicações em nuvem em conformidade com regulamentações mais rapidamente
- Cal.com: ferramenta de agendamento que ajuda a marcar reuniões sem a troca repetitiva de e-mails
- Crowd.dev: centraliza dados de comunidade, produto e clientes para ajudar a entender quais empresas estão participando de projetos open source
- Documenso: alternativa open source ao DocuSign, com o objetivo de conquistar confiança por meio de self-hosting e da possibilidade de examinar seu funcionamento interno
- Erxes: alternativa open source ao HubSpot, permitindo criar experiências para diferentes tipos de negócios por meio de um único XOS
- Formbricks: permite enviar pesquisas a grupos segmentados de usuários em qualquer ponto da jornada do usuário, coletando até 6 vezes mais insights com micropesquisas direcionadas
- Forward Email: serviço gratuito de encaminhamento de e-mail para domínios personalizados, usado há mais de 6 anos por criadores, desenvolvedores e empresas
- GitWonk: ferramenta open source de documentação técnica projetada e construída com foco na experiência do desenvolvedor
- Hanko: ferramenta open source de autenticação e gerenciamento de usuários para a era das passkeys, integrável a apps web e mobile em poucos minutos
- Infisical: plataforma open source com criptografia de ponta a ponta para gerenciar secrets e configurações com segurança em equipes, dispositivos e infraestrutura
- Novu: infraestrutura open source de notificações para desenvolvedores, oferecendo componentes e APIs para gerenciar todos os canais de comunicação em um só lugar
- OpenBB: democratiza a pesquisa de investimentos por meio de um ecossistema financeiro open source, permitindo realizar pesquisas de investimento de qualquer lugar com o OpenBB Terminal
- Sniffnet: ferramenta de monitoramento de rede que ajuda a rastrear facilmente o tráfego de internet
- Typebot: fornece blocos para criar experiências de chat únicas, que podem ser incorporadas em qualquer lugar do app para coletar resultados
- Webiny: CMS serverless open source de nível empresarial, com ênfase em propriedade dos dados, escalabilidade e personalização
- Webstudio: selecionado como alternativa open source ao Webflow
1 comentários
Opiniões no Hacker News
Olá, como muitos de vocês sabem, eu sou a pessoa que criou o htmx e posso responder a perguntas relacionadas
O htmx ganhou bastante popularidade graças ao vídeo do fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) e a uma série de vídeos do popular streamer da Twitch ThePrimeagen
Para leitores do HN, a coletânea de textos que escrevi sobre htmx e hipermídia em geral, https://htmx.org/essays, também pode ser interessante, assim como o livro que publiquei recentemente com alguns autores sobre hipermídia, htmx e Hyperview, uma hipermídia para mobile: https://hypermedia.systems
Naturalmente, sou fã de htmx, mas considero que o ponto central mais profundo é a hipermídia. Mesmo que você não planeje usar htmx no desenvolvimento do dia a dia, é um conceito que vale a pena explorar
Também há muitas bibliotecas excelentes orientadas a hipermídia, como o Hotwire da 37signals ou https://unpoly.com, minha favorita depois do htmx
Ajuda muito muitos desenvolvedores Django
Alguns meses atrás, ao criar um recurso de curtidas em posts, antes do htmx eu teria de chamar um servidor de API JSON com jQuery e atualizar a contagem de curtidas, mas com HTMX a sensação foi de simplesmente usar HTML comum junto com a lógica do Django
É uma das melhores coisas que descobri até agora, e o processamento de formulários também é muito fácil. HTMX melhora bastante tanto a experiência do usuário quanto a experiência do desenvolvedor
Considerando que, mesmo em projetos muito populares, normalmente os contribuidores existentes cuidam da maior parte do código, isso é um forte sinal de crescimento
https://devboard.gitsense.com/bigskysoftware/htmx
Como observação, essa é uma ferramenta que eu criei
Dei uma olhada rápida no site e nos exemplos, e parece que a abordagem dá ênfase a respostas HTTP do servidor contendo marcação completa e, com base nisso, atualizando o estado do cliente — ou seja, reescrevendo o DOM
Fico curioso se o htmx também oferece concessões para triggers exclusivamente do cliente ou conteúdo gerado no cliente
A vantagem dos frameworks de cliente atuais, centrados em JavaScript, é poder transferir o máximo possível de trabalho para o navegador e reduzir o uso de dados e CPU no servidor. Em apps em escala web, isso faz uma grande diferença
Fico curioso se o HTMX também consegue atender a esse objetivo de engenharia ou se é um projeto com um propósito completamente diferente. Entendo que um cliente como o Facebook não seja orientado a hipermídia, mas, de qualquer forma, a comparação será difícil de evitar
Parece natural, quase autodocumentado, e é bem projetado. Realmente parece uma extensão natural do HTML
Para mim, a única peça que falta no htmx é um modelo de componentes, e, para quem procura algo assim, ele parece combinar muito bem com Astro[1]. O Astro permite definir e usar componentes HTML sem o peso de runtime de algo como Vue ou React
[1] http://astro.build
Htmx me lembra o Tailwind. Afinal, ele cria nomes e valores de atributos que uma única biblioteca lê em tempo de execução
Não precisar de build de front-end é uma vantagem enorme para a maioria dos desenvolvedores que não querem mexer com npm e webpack, e que nem deveriam precisar fazer isso
O limite de tamanho das páginas parece ser algo como um pequeno app de página única; se ficar grande demais, dá para dividi-lo em outro app de página única
O que desenvolvedores React/Vue provavelmente mais vão sentir falta é da perspectiva de haver um único objeto representando o estado global e uma função, definida hierarquicamente na base de código de componentes, que o renderiza como UI
Só que essa própria perspectiva também é pesada, gera muitas divergências de opinião e desgaste emocional, e ainda traz junto o build de front-end e suas variações confusas
Eu ainda não uso, mas já sou um grande fã
Ótima notícia
No último ano, usei htmx e tive bons resultados e experiências gratificantes; ele foi especialmente excelente ao fazer renderização server-side com hiccup em Clojure
Quando você entende o htmx, chega a ser quase surpreendente o quanto ele é simples e flexível. É difícil acreditar que o HTML não tenha evoluído desse jeito como hipermídia
Fica muito claro que o desenvolvimento web deveria ter evoluído assim. Espero que um dia o que o htmx está fazendo com JavaScript seja incorporado diretamente ao HTML e aos clientes de navegador
Se você vê o htmx erroneamente como uma espécie de derivado do Angular, ou não entende o significado de ele avançar a arquitetura de hipermídia, recomendo muito ler os ótimos textos do site. Assim você vai entender o que é REST e por que o verdadeiro HATEOAS importa: https://htmx.org/essays/
Também há um livro gratuito: https://hypermedia.systems/
Há 10 a 15 anos, em vez de expandirmos e enriquecermos a hipermídia, que era uma ideia nova e poderosa da web inicial, entramos por um caminho equivocado e custoso ao tentar recriar clientes pesados sobre a web com arquiteturas de API JSON
Fico feliz que o htmx exista e funcione bem para muita gente, mas no meu trabalho ele muitas vezes não foi a melhor opção. E tudo bem
É ótimo que a web tenha podido crescer de várias formas, e não precisamos achar que ela necessariamente deveria ter evoluído em uma única direção
O maior erro do desenvolvimento web nos últimos dez anos, mais ou menos, foi a ideia de que deveria haver uma única resposta certa
Seja para criar o próximo Gmail ou um blog estático, o cargo cult da indústria diz que tudo deve ser feito do mesmo jeito, mas o bom senso diz que não
Isso seria suficiente para mais de 98% da web. Para os outros 1,9%, bastaria usar uma pequena biblioteca JavaScript
Só os 0,1% restantes seriam webapps em JavaScript puro
Parece a mesma ideia de espalhar alguns atributos no HTML para tornar dinâmicos os casos simples
Angular 1, Vue e muitos outros frameworks começaram assim e, depois de ganharem certa popularidade, cresceram para se tornar frameworks completos de aplicação de página única por causa da demanda real por casos mais difíceis
Se eu tivesse que escolher um framework “tipo Angular 1”, escolheria um que documentasse claramente seus limites e oferecesse um caminho claro para usar um framework maduro de aplicação de página única quando fosse preciso ultrapassar esses limites. Se alguém conhecer um framework assim, compartilhe
Eu era fã do HTMX “antes de ele ficar legal”
Fico muito contente com a atenção e o sucesso recentes, e também estou me divertindo bastante com as provocações em tom de brincadeira e a reação vindas do pessoal de front-end, que parece acreditar que a Web foi inventada em 2013 e que eles construíram aquela cidade
Tenho esse viés desde a época do Backbone.js; mesmo então eu entendia parte do sofrimento, mas era meio cético
Depois veio o React e, quando gente jovem e cheia de energia começou a transformar sites muito simples de 5 páginas em máquinas de Rube Goldberg de frameworks de front-end, eu saquei minhas fichas de tecnologia e não mexi mais nisso
Os detalhes de implementação são bem diferentes, mas a ideia de aplicações baseadas em hipermídia estava no centro de tudo o que fazíamos
Infelizmente, no longo prazo, isso não conquistou a cabeça das pessoas, e o desenvolvimento guiado por blogs — ou seja, cargo cult — substituiu nossos esforços
Agora que a popularidade do HTMX parece estar subindo, sinto uma certa recompensa. É bom ver que não éramos os únicos a pensar nesses conceitos
Claro, se o conceito era forte, isso talvez signifique que minha execução deixou a desejar, então talvez eu não devesse ficar tão feliz assim
Também ouvi dizer que a banda vendeu as guitarras e comprou toca-discos
Também ouvi dizer que reescreveram um endpoint HTTP para retornar JSON e que isso era REST
Também ouvi dizer que a banda vendeu os toca-discos e comprou guitarras
Também ouvi dizer que reescreveram um endpoint HTTP para retornar fragmentos de HTML com template e que isso era HATEOAS
Estou perdendo o fio, recuperando, perdendo e recuperando
Só que o Backbone era um pouco solto demais e, até o Angular aparecer, não parecia muito corporativo
De todo modo, esse fluxo de aplicações web ficou popular ao meu redor porque separava back-end e front-end, e um único back-end, geralmente REST/JSON, podia alimentar clientes mobile e web separadamente
Foi por isso que criamos aplicações de página única, mas agora isso parece ter sido esquecido de novo
No meu mundo, fazia sentido para apps atrás de login. Mas “eles” queriam transformar até sites públicos da internet, como lojas virtuais, em aplicações de página única
Também dá para entender. Criei alguns sites com Gatsby, e a navegação é absurdamente rápida, ao mesmo tempo que eles são indexados por mecanismos de busca
Só que, em alguns casos, isso foi ficando cada vez mais complexo, até chegar a coisas como React no lado do servidor. Felizmente, eu não precisei mexer nisso
Por outro lado, espero que o htmx — e, de forma mais geral, a hipermídia — seja aceito como uma ferramenta. É útil, mas no fim é só uma ferramenta
Espero que também seja aceito assim por pessoas de front-end que por um tempo não pensaram muito profundamente em hipermídia
Não vejo as duas abordagens como mutuamente exclusivas, e concordo com o conceito de aplicações web transicionais de Rich Harris, isto é, uma forma de misturar as duas abordagens
Só traço a linha em um ponto diferente do dele sobre quando abandonar a hipermídia e passar para uma abordagem mais sofisticada do lado do cliente
Eu certamente acho
Comecei com Perl em 1996 e passei por praticamente todas as ondas: PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL e NextJS
Htmx parece um ramo que foge dessa corrente, e vale a pena refletir sobre ele
Htmx faz uma boa pergunta: “A complexidade do seu trabalho está essencialmente no servidor ou no cliente?”
Na maioria dos sites, a complexidade está essencialmente no servidor. Na maior parte do tempo, não estamos criando Figma ou Google Sheets. Muitos sites, mesmo com bastante interação, são apenas apps CRUD com uma interface bonita
Frameworks como NextJS tentam corrigir problemas de cliente excessivamente complexos levando o React para o servidor, mas muitas vezes acabam aumentando a complexidade em vez de reduzi-la
Então não seria melhor tirar o React da stack? Se for um cliente complexo, dá para pular o DOM e JavaScript e usar canvas com WebAssembly compilado. Se for um servidor complexo, dá para usar atualizações granulares do DOM conduzidas pelo servidor
O problema que vejo nessa abordagem é que, mesmo que a complexidade da maioria dos sites esteja no servidor, quase sempre há algumas tarefas de alta complexidade que precisam estar no cliente. Edição de imagens, ordenação, filtragem e cálculos em tempo real, gestos de arrastar e de toque, e assim por diante
É necessária uma abordagem híbrida. Apenas ser compatível não basta. Dá para usar htmx e React na mesma página web, mas é preciso isolá-los um do outro. O que eu quero não é isolamento, e sim integração fundamental
O framework ideal deveria oferecer suporte a atualizações reativas e granulares do DOM, ao mesmo tempo em que se integra estreitamente ao WebAssembly compilado responsável por tarefas complexas no cliente
Quero escrever todo o código em uma linguagem forte que não seja JavaScript. O depurador deve lidar tanto com o servidor quanto com o cliente, e a diferença entre os dois deve desaparecer. Deve ser desenvolvimento full-stack de verdade, ou seja, uma aplicação de stack única
Clojure + ClojureScript parece se aproximar de uma aplicação de stack única, mas só superficialmente
Se surgisse um framework matador em Common Lisp, acho que uma aplicação de stack única se encaixaria perfeitamente
A abordagem híbrida é a abordagem de ilhas defendida pelo Astro: https://docs.astro.build/en/concepts/islands/
Essa abordagem combina bem com htmx e seus semelhantes, e em projetos com htmx estamos usando JavaScript vanilla simples nas partes que precisam de interação
Para projetos pequenos e médios e equipes pequenas, isso pode ser suficiente. É realmente refrescante abrir as ferramentas de desenvolvedor, apontar para uma parte da página e conseguir entender tudo sobre aquela parte olhando apenas o HTML e pequenos trechos de JS
Você programa do mesmo jeito em C#, seja no servidor ou no cliente. No primeiro carregamento da página, tudo é renderizado no lado do servidor e, depois, o WebAssembly vai assumindo progressivamente, começando a carregar código C# no cliente para acelerar interações de UI que não precisam de dados do servidor
Funciona bem, mas o desafio atual é reduzir o tamanho dos arquivos WebAssembly. Hoje eles estão na casa de vários MB
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Parabéns. Foi divertido criar um projetinho com Htmx, mas acabei usando bastante openlayers e escolhi outra coisa
Bibliotecas de mapas são conhecidas por pesar bastante em JavaScript no lado do cliente, e Svelte foi uma ferramenta melhor para esse trabalho
Pretendo usá-lo novamente em projetos Golang no futuro e acompanhar sua evolução
Se o app precisa de um frontend simples ou de complexidade média, especialmente se você já usa fragmentos de template[0], recomendo muito experimentar HTMX. Mesmo vindo do mundo JavaScript, o trabalho é bem divertido
E quem administra a conta do Twitter[1] é muito engraçado
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
É difícil levar o htmx a sério como ferramenta para construir webapps ou sites modernos. Parece que ele torna impossível criar recursos que os usuários passaram a esperar
Por exemplo, busca facetada que filtra datas por antes/entre/depois, mas só mostra os filtros quando o usuário quer, ou a capacidade de alternar a tela de resultados para outra coluna, um mapa ou uma visualização desenhada em canvas, como um gráfico
Talvez dê para fazer algumas coisas com htmx, mas em algum momento você vai acabar precisando de JSON
O Angular também consegue fazer isso, e usando algo como SolidJS dá até para construir de forma bem prazerosa
Uma API JSON pode ser reutilizada em outros apps, mas htmx dá a impressão de que alguém reinventou o Thymeleaf
Eu pensava a mesma coisa, mas o vídeo aborda em detalhes como implementaram busca facetada com htmx
A segunda parte provavelmente acabaria sendo tratada com JavaScript escrito diretamente ou com hyperscript
Só construindo de fato e usando intensamente para saber se é uma boa abordagem, mas certamente consigo pensar em cenários em que ela se encaixa bem
A observação sobre API JSON é válida. Se você precisa de uma API pública, isso deve entrar na decisão. Mas nem todo projeto tem essa restrição
Até smartphones não têm problema algum para pesquisar em uma tabela de mil linhas
Nesse caso, eu entregaria ao usuário um conjunto amplo de dados com htmx e depois permitiria uma filtragem em tempo real mais refinada com JS
Se quiser tornar pesquisáveis até os dados que não aparecem inicialmente, basta enviá-los junto com uma classe CSS oculta e remover essa classe quando forem encontrados na busca
htmx, como qualquer outra tecnologia, se encaixa muito bem em um conjunto específico de problemas. Desde que você não tente forçá-lo a fazer truques nos quais ele não é bom, tudo bem
Coisas assim são complexas o bastante para exigir algum nível de scripting completo, e eu não sou contra isso em si
https://htmx.org/essays/hypermedia-friendly-scripting/
Pelas voltas que minha carreira deu, acabei passando quase batido pelas guerras de frameworks JavaScript de front-end, então é bom ver o bom e velho HTML comum voltando fortalecido
Isso é um retrocesso em termos de degradação progressiva
Acho que precisamos de exemplos impressionantes feitos com htmx. Seria bom ter exemplos “made with htmx” que abrissem caminho para um novo tipo de experiência web
As pessoas estereotiparam htmx como algo para casos de uso simples, que não chegam a exigir “armas pesadas”
Há alguma verdade nisso, mas é uma visão limitada. A abordagem de voltar para o servidor associada ao htmx é uma categoria própria, que por vários motivos não foi explorada antes
HTMX é sobre ressuscitar uma categoria antiga de apps de uma forma que não depende do backend
Ele não faz nada novo nem algo que justifique uma “nova categoria de apps”
É uma forma de criar hipermídia, ou seja, sites centrados em conteúdo, como catálogos de compras, fóruns, front-ends administrativos e blogs
É parecido com jquery/liveview/turbolinks, mas independente do backend e sem precisar manter muita lógica JS de front-end, ou nenhuma
Quando você precisa de interações pesadas como Google Docs ou Figma, os benefícios oferecidos pelo htmx diminuem bastante
https://htmx.org/essays/a-real-world-react-to-htmx-port/
É um front-end de e-commerce escrito com HTMX e Hyperscript
https://www.makaron.cz/
Dá para fazer um front-end TodoMVC com HTMX, mas o que usar no backend? Go, C#, Rust e algumas outras opções parecem naturais, mas sempre depende do contexto
Menciono C# porque ASP.Net MVC + Razor parece se encaixar de forma muito limpa no paradigma HTMX
Não tenho nenhuma relação com eles, mas foi feito com htmx e um pouco de JS para funcionalidades mais complexas
Considerando que o htmx tem explicitamente o objetivo de ampliar uma boa abordagem antiga, não sei bem se ele pode oferecer um “novo tipo de experiência web”
No começo, htmx parece bom, mas, quando você tenta criar algo que normalmente usaria JavaScript — seja vanilla ou com framework —, como um botão de dropdown, acaba considerando hyperscript
Aí, ao ver os exemplos, você não gosta de ver algo parecido com frases dentro do código e acaba passando para outra coisa
Talvez seja preciso experimentar htmx sem hyperscript, ou talvez dar mais tempo ao hyperscript
Mas, se eu imagino que vou manter isso por alguns anos, é estranho demais, e não quero ficar preso a algo se depois eu nunca mais for usar
O lado do htmx não se importa nem um pouco com qual ferramenta de interação no lado do cliente você usa, então isso é uma questão separada de htmx ser útil ou não
Pessoalmente, se eu estivesse tentando evitar ferramentas de build de JS etc., escolheria htmx + Alpine.js
Como dar conta disso quando a escala aumentar e ficar mais complexo?
Já ajudei em uma aplicação que usava htmx e havia dois problemas. Gostaria de saber se alguém teve uma experiência parecida, se eram problemas causados por uso incorreto da tecnologia ou se há algum trabalho em andamento para resolvê-los
Primeiro, foi necessário muito middleware customizado nos controllers para decidir se um endpoint deveria retornar o HTML da página inteira ou apenas o fragmento de que o htmx precisava
Do lado do htmx parece simples, mas provavelmente é algo que todo projeto que usa htmx acaba tendo que recriar
Segundo, era preciso fazer bookkeeping em torno de
hx-trigger. Quando a UI fica complexa, muitos elementos precisam reagir a mudanças externasEm vez de ler algum estado e esperar que o framework agende a atualização, era preciso gerenciar manualmente a lista de eventos aos quais reagir
Alguém mais teve essa mesma impressão?