Maturidade do Htmx

Sou a favor
HTML = HyperText Markup Language
HTTP = Hypertext Transfer Protocol

não é Json Transfer Protocol #paz

Olá! Minha contribuição de 2 centavos sobre o assunto:

Visão geral:

Curto muito novas tecnologias, possibilidades, formas novas de se fazer as coisas... mas ao mesmo tempo, esse tipo de novidade tem 2 problemas na minha visão, que é a aceitação e o quanto isso pode realmente ajudar. Ora, não adianta algo ser amplamente conhecido/usado/aceito mas ser inútil no fim do dia (hype, tipo o Devyn) ou ser uma ferramenta maravilhosa, mas pouco difundida, ou com comunidade ativa pequena ou em desenvolvimento (diria aqui algo como o Godot 4, é o unico que vem na cabeça, mas 90% de certeza de isso gerar controvérsias). Htmx pra mim cai nessa linha, pois no fim do dia irá competir com os gigantes do front end para um lugar ao sol, como o React e o Angular, e isso leva ao ponto de que dificilmente vão existir muitas vagas relacionadas a tecnologia, ainda mais buscando profissionais que tenham pouco tempo de "voo". Geralmente o seu uso é demandado em projetos que já existem a algum tempo, e um dev ou dois, talvez "emocionados", sugeriram o uso e por N motivos acabou por se aceitar e usar.

Isso cria outro tipo de problema: ferramentas novas não possuem um code-style/idiom bem definido, pois, como eu disse, geralmente não existe uma comunidade ativa para definir uma convenção. O que existe são vários snipets de código soltos e alguns projetos pequenos, cada um a sua maneira (sendo beeeeem simplório). É diferente de um projeto de uma linguagem/framework já antigo, por exemplo o Spring, que já tem essa característica intrísseca.

Agora, respondendo as suas perguntas

A tecnologia está ou estará robusta suficientemente para grandes aplicações? - Você citou o PHP, e eu tenho a mesma opinião, porém partindo de outra perspectiva. O PHP em sí é uma ferramenta fantástica para entregar código rápido, que permite muita liberdade, mas essa liberdade também é um problema. Existem diversos projetos problemáticos feitos em PHP, alguns que eu já vi e participei de melhorias, que ficaram dessa forma por conta dessa liberdade.
Mas indo ao ponto, depende. Não dá pra dizer sim ou não nessa resposta, primeiro pois eu nunca testei a fundo o Htmx, e segundo porque não tem uma comunidade madura o suficiente para dizer isso.

Quanto a segurança, seria mais fácil para uma página construída com esta tecnologia ser invadida? - Nesse ponto, eu entendo que a brecha de segurança é primariamente de responsabilidade de quem está codificando a aplicação usuária, e depois é baseada no software usado. Brechas de segurança são no seu cerne, nuances que causam um efeito extremamente destrutivo (ou não, dedpendendo do contexto). Tudo depende do contexto. Não dá pra dizer se sim ou se não sem um amplo estudo da ferramenta, muitos anos de uso, melhorias, versões, novas funcionalidades....

Dizer se uma ferramenta é boa ou não é uma questão que pode ser profunda demais, pois depende do que você espera dela. Se seu objetivo é de fato um projeto grande com muitos acessos, provavelmente existem mais pessoas envolvidas, e geralmente a escolha mais simples e funcional é o melhor caminho (eu mesmo escolheria React para esse tipo de projeto). Mas se você quer fazer um projeto pessoal, ou mesmo uma POC para um novo produto que pode ter esse potencial... por que não?

Acho que perguntar em um fórum na internet não é a melhor opção para tomar uma decisão. Pesquisar e testar por conta própria sempre é a melhor opção. Aprenda, analise, teste, adapte, melhore e tire suas conclusões práticas. Você vai saber se ela é robusta ou não para o seu projeto ou grandes aplicações. Jamais se baseie em opiniões de apenas uma pessoa por mais que ela diga/seja especialista em alguma coisa. Pra mim não existem gurus em nada, muito menos em tecnologia. Os tais "gurus" especialistas também erram, como todo mundo.
Dito isso, pesquise sobre a equipe que desenvolve essa tecnologia, sobre empresas que migraram com sucesso para HTMX ou que adotaram como uma opção eficiente, sobre como vem sendo adotado pelas comunidades de desenvolvedores. Vejo mais uso em Go e Python, mas já ando encontrando casos/artigos sobre Rust + HTMX também.
A questão de grande adesão ou não pra mim não faz sentido, justamente pelo que falei, prefiro eu mesmo tirar as conclusões e se vc for seguir a lógica, toda tecnologia com grande adesão começou com zero adesão e foi crescendo.

Cara, nos últimos anos todas as minhas frustrações na área de programação geralmente vem do mesmo lugar: Frontend. Eu utilizei muitos frameworks durante esses anos, e apesar de achar alguns infinitamente superior a outros, todos eles tem pontos semelhantes. Em geral, diria que a semântica de soluções no front muda muito pouco entre ele, apesar da sintaxe diferente. Por essa razão nunca achei um framework js que me trouxesse algum prazer em programar no mesmo (apesar do Svelte chega perto)

Gerenciar o estado no front é um inferno. E quando o Htmx saiu eu simplesmente percebi que era uma perda de tempo. Para meus projetos pessoais eu sempre utilizo Htmx para o estado principal e alpinejs para coisas como modalsl e drop-downs. Eu ainda tenho que fazer algumas métricas para definir se estou mais produtivo ou não. Mas com certeza estou mais feliz. Pois tudo ficou mais simples.

Sobre suas perguntas, a biblioteca é madura o suficiente para entrar em produção. E quanto a segurança: basta sanitizar o que o usuário manda se for renderizar na página. Porém isso é a prática recomendada mesmo em stack baseadas em json.

Eu vi alguns comentários preocupados com a adoção. A biblioteca apenas faz requests quando eventos acontecem em algum elemento. Mesmo que você não ache outros programadores que o conheçam. Eles não vão levar mais de 15 minutos para aprender o basico. Na minha opinião vale apena a tentativa.

Não responderei às suas perguntas porque elas levariam a uma série de 'depende', mas gostaria de compartilhar minha visão sobre o HTMX:

Há apenas alguns anos, todos estavam falando sobre Aplicações Web Progressivas e a abordagem 'offline first'. Em vez disso, somos apresentados à perspicácia do HTMX, que estende e generaliza a ideia central do HTML como hipertexto, abrindo muito mais possibilidades diretamente na linguagem.

Sou um desenvolvedor que já trabalhou em projetos tanto com Angular, React e VueJS. De fato, essas estruturas estão ficando cada vez mais inchadas; problemas de design nelas são resolvidos empurrando mais conceitos. Um exemplo disso é como o React chama a função de criação do componente sempre que o estado muda, e para lidar com isso, precisamos usar algum 'helper' fornecido pela equipe do React. Veja o SolidJS, onde esse problema simplesmente não existe.

Por mais que tenha citado o React, não estou aqui para discutir pontos fortes ou fracos dessas ferramentas; quero apenas mostrar como as estruturas de frontend estão evoluindo para algo mais complexo. Se não confia em mim, pergunte ao seu colega de backend ou a um iniciante em frontend.

Para concluir, deixo o link de um artigo que se encontra no próprio site do HTMX, que é ótimo: https://htmx.org/essays/a-response-to-rich-harris/.

Por fim, não estou dizendo que Angular, React, Vue, etc. são ruins, até porque as uso em projetos 'reais' e nunca usei o HTMX em um. Isso é apenas um ponto de vista do atual estado dos frameworks Javascript.