O paradoxo do site estático

• Mesmo sites simples, como um blog pessoal ou uma página de contato, acabam ficando nas mãos de usuários comuns em CMS como o WordPress, enquanto sites HTML estáticos, paradoxalmente, são mais fáceis de operar para engenheiros especializados
• Para criar um site estático por conta própria, é preciso lidar sozinho com várias etapas intermediárias, desde comprar um domínio, escolher uma hospedagem e fazer a configuração de DNS até selecionar um SSG e montar um pipeline de deploy
• Engenheiros usam GitHub Pages ou Cloudflare Pages com hospedagem gratuita e domínio personalizado, mas usuários comuns acabam dependendo de serviços mais caros e pesados mesmo quando um site estático seria suficiente
• O SuperHTML foi apresentado como o primeiro servidor de linguagem HTML a fornecer diagnósticos ao usuário, enquanto as ferramentas de diagnóstico existentes em geral estão presas a frameworks específicos de frontend, o que dificulta o uso apenas com HTML vanilla
• Se não conseguirmos tornar o desenvolvimento web simples mais fácil, a web se afastará dos não especialistas, e usuários comuns serão empurrados para espaços fechados como as redes sociais

---

O paradoxo de os sites estáticos ficarem mais difíceis

• Dois exemplos de sites pessoais são colocados em contraste
  • Um deles é um CMS complexo escrito em PHP e precisa de servidor web, vários workers, cache Redis e banco de dados SQL
  • O frontend também é carregado como uma Single Page Application, solicita o conteúdo em JSON e depois o recompõe no cliente
  • O outro é composto por arquivos HTML estáticos e um ou dois arquivos CSS, sem JavaScript
• À primeira vista, parece que usuários comuns usariam um site estático simples e engenheiros profissionais adotariam uma estrutura complexa, mas na prática acontece quase o contrário
• Para um usuário comum operar diretamente um site estático, é preciso passar por várias etapas
  • Comprar um domínio
  • Encontrar uma plataforma de hospedagem
  • Configurar o DNS
  • Escolher um SSG ou criar um por conta própria
  • Montar um pipeline de deploy
• Em contrapartida, engenheiros de software podem aproveitar hospedagem gratuita e suporte a domínio personalizado com GitHub Pages, Cloudflare Pages e afins
• Como resultado, mesmo nos 99% dos casos em que um site estático seria suficiente, usuários comuns ficam presos a soluções complexas que custam mais e consomem mais recursos computacionais

A necessidade de ferramentas que facilitem a web simples

• Uma palestra na SquiggleConf, em Boston, tratou da experiência de implementar um servidor de linguagem para HTML e a conclusão levou à questão da acessibilidade da web
• O SuperHTML foi apresentado como o primeiro servidor de linguagem HTML a fornecer diagnósticos ao usuário, e o texto relacionado chegou à página principal do Hacker News
• Linters existem, e diagnósticos no editor também são possíveis, mas normalmente estão vinculados a frameworks específicos de frontend
  • Por isso, usuários acabam escolhendo um framework mesmo quando na prática não precisam dessa complexidade
• A web não pertence apenas a engenheiros de software, e quanto mais ela se torna complexa, mais usuários comuns são empurrados para dentro da cerca das redes sociais
• Startups e big techs têm incentivos econômicos desalinhados, então é difícil que resolvam esse problema no lugar dos outros; é necessário tornar a web simples mais fácil de criar

[GN⁺]

Opiniões do Hacker News

• Tive muitas experiências amargas tentando convencer equipes de marketing a abandonar o WordPress e usar sites estáticos
  No fim, o ponto central é a facilidade de edição. Um site WordPress é otimizado para editores, não para hospedagem, responsáveis técnicos, contabilidade ou leitores, e as pessoas que editam o site acabam decidindo como ele será implementado
  Se você oferecer a escolha entre um site que renderiza em menos de 100 ms, é totalmente seguro e tem custo de hospedagem zero, mas exige arquivos Markdown e um pouco de deploy com Git, e um WordPress lento, caro, vulnerável e que precisa de manutenção constante, mas tem uma boa experiência de edição, elas sempre escolhem WordPress
  Sempre me confunde por que essas pessoas têm poder de escolha, mas, mesmo repetindo o mesmo experimento várias vezes, o resultado foi sempre o mesmo

  • Isso soa bastante hostil ao usuário. O “trabalho a ser feito” dos profissionais de marketing é criar conteúdo e colocá-lo diante do público-alvo, então é natural que a experiência de edição venha antes de segurança ou velocidade de renderização
    Não vejo por que seria estranho escolher WordPress em vez de aprender um editor de texto e Git. O experimento deveria comparar o WordPress com uma ferramenta que ofereça uma boa experiência de edição, mas que por trás gere um site estático e faça deploy via Git. Aí requisitos secundários como segurança e velocidade poderiam passar a fazer sentido
  • Você mesmo respondeu. A tecnologia proposta não atendia aos requisitos deles. Um site de marketing deve mesmo ser otimizado para editores, e isso não é uma falha dos profissionais de marketing, é uma falha dos desenvolvedores
  • Esse é o ponto. Eu também sou engenheiro e deixei o WordPress há alguns anos; hoje uso Ghost. Mas o WordPress dá uma sensação de controle em que basta pesquisar “online store” para aparecerem 100 plugins, incluindo o WooCommerce, que parecem plataformas completas de e-commerce
    Mais do que um blog, ele é quase uma aplicação personalizada que pessoas não especialistas conseguem montar na marra, com cliques e arrastar-e-soltar, de acordo com as funcionalidades que querem. Nem precisa programar, até o site ser invadido ou surgir uma funcionalidade personalizada que exija um engenheiro de verdade
    Com Hugo, Ghost etc., a conversa vira “para isso você precisa de outra plataforma”, e essa plataforma acaba sendo Shopify, um sistema contábil, um plugin de rede social/membros, um quadro de vagas etc. O WordPress virou algo que pode ser transformado em qualquer coisa
    Quando alguém dizia a um consultor o que queria, a resposta era “configuro isso para você no WordPress”; e, como todo mundo usava WordPress, era fácil encontrar alguém para resolver problemas, ajustar um plugin ou adicionar um hook de envio de e-mail. A era dos consultores PHP criou o domínio do WordPress
    O problema é que a maioria, inclusive das soluções pagas, não é uma solução completa. Assim que você começa a usar, percebe rápido que o WordPress impõe restrições absurdas. Não dá para projetar uma loja online fora do desastre de desempenho do sistema de entidades/metadados, em que até consultas de tamanho moderado levam 5 segundos e criam 50 consultas auxiliares não otimizadas. Alguns plugins até contornam o WordPress e criam suas próprias tabelas no banco de dados
    Fora blogs, o WordPress tem uma arquitetura péssima, mas é usado como ferramenta para tudo. Outros CMS não fazem isso, por isso as pessoas não os usam
  • Você está misturando duas funções diferentes. O WordPress oferece um sistema de gerenciamento de conteúdo de que os usuários gostam, e a forma de servir esse conteúdo pode ser facilmente separada
    O conteúdo ainda pode ser distribuído por uma CDN como arquivos estáticos gerados. Um site estático não precisa exigir Markdown e Git
  • Eles têm poder de escolha porque são as pessoas que lidam com isso todos os dias. O objetivo é publicar conteúdo rapidamente, e o conteúdo varia muito, desde coisas que não se encaixam bem em Markdown, como tabelas, até imagens que precisam de hospedagem separada
    Procurei por muito tempo uma cadeia de ferramentas em que até um estagiário sem nenhuma experiência técnica conseguisse publicar alterações sem se enroscar em detalhes técnicos, mas ainda não encontrei
    O mais próximo é colocar um gerador de site estático sobre um CMS headless, mas, sinceramente, todos são ruins

• Em 2016, quando trabalhei em uma agência que fazia sites institucionais para negócios locais, um cliente pediu para colocarmos no site que eles tinham feito um pequeno iframe para o sistema de reservas. O que eles enviaram foi um documento do Word, e descobrimos que eles o exportavam para HTML e o colocavam em uma hospedagem compartilhada barata.
  Para eles, funcionava muito bem. Conseguiam manter o cardápio online sempre atualizado, porque bastava exportar diretamente do documento do Word que usavam para criar o cardápio impresso. Na época, internamente, demos uma meio que zoada, mas hoje penso nisso com certo arrependimento. Quando há um milhão de coisas mais importantes, como tocar um restaurante, isso na verdade é uma forma genial
  Criar sites estáticos ainda é mais fácil. O problema é que as ferramentas de autoria que geram HTML hoje são ruins, ou, mesmo quando são decentes, vêm acompanhadas de algum processo que precisa rodar no servidor para servir o site

  • Gosto de ver negócios resolvendo problemas desse jeito. Se funciona, funciona.
    Meu trabalho não é zombar dizendo “daria para fazer melhor”, mas melhorar a solução deles e garantir que a solução que eu ofereço funcione tão bem quanto a existente — se possível melhor — sem atrapalhar o sucesso que eles já conquistaram.
    Muitos desenvolvedores não gostam de admitir, mas essas soluções web improvisadas muitas vezes funcionam melhor do que várias estratégias que um desenvolvedor web experiente implementaria sozinho.
    O que importa é o que o negócio oferece e como ele se relaciona e interage com os clientes. Às vezes, exportar um documento do Word para HTML basta. A tecnologia pode melhorar isso, mas a verdadeira mágica está nas pessoas que operam o negócio.
    Encontrar maneiras de melhorar esse tipo de solução às vezes é, de fato, bem difícil. Dá para criar um site melhor e publicá-lo em uma infraestrutura sofisticada, mas no fim os clientes gostam mais? O negócio melhora? Essa parte pode não ser nem um pouco trivial
  • Há tempos reclamo do desaparecimento do FrontPage. A gente ria do HTML horrível que ele gerava, mas, ao mesmo tempo, era um programa que permitia a pequenos empresários e pessoas comuns atualizarem sites pequenos e baratos sem preocupações de segurança, desde que escolhessem uma boa senha.
    Há anos procuro uma boa alternativa que gere HTML mais correto que a exportação do Word para HTML e ofereça mais opções
  • O cardápio de um restaurante a que fui neste verão na CDMX era um link de prévia pública de um documento do Figma. Achei isso hilário, mas ao mesmo tempo fiquei feliz porque funcionava muito bem.
    Gosto dessas coisas. Há muitos sites de arquivo HTML único feitos com Vue template, além de sites publicados como documentos públicos do Notion ou bibliotecas de fotos inline do iCloud. É impressionante como ficou fácil e amplamente possível simplesmente conectar as coisas, e também faz perceber como frequentemente complicamos tudo ao tentar construir do zero.
    Quando estou sem tempo, também gosto de coisas como mmm.page para montar rapidamente pequenos microsites ou sites descartáveis. É divertido explorar essas ferramentas
  • Para um cliente, criei um “app de dados” que faz todo tipo de coisa sofisticada, como gerenciamento de metadados e verificações de qualidade.
    Mas a “documentação” de algumas páginas é um conjunto de tabelas com datas e textos, mantido pelo próprio cliente. A solução a que chegamos acabou sendo parecida: eles colocam as tabelas em um documento do Word e nos entregam; nós exportamos para HTML/CSS e colocamos no lugar certo.
    Não é elegante nem escalável, mas, para aquele uso específico, é de longe o jeito mais fácil
  • Logo após a invasão russa da Ucrânia, a resposta humanitária na Alemanha também funcionou assim até que os órgãos oficiais alcançassem a situação, dias ou semanas depois. Notion, Telegram, WhatsApp e Google Docs salvaram a situação.
    Foi maravilhoso na época e continua sendo maravilhoso agora. Silenciosamente, realizamos o sonho de levar a computação a todos

• Aqui em Asheville estamos sofrendo bastante com esse problema. Mesmo quando o serviço de celular mal tinha voltado, todo mundo estava usando um 3G ruim e caindo, e nenhum dos sites de onde precisávamos obter informações básicas de sobrevivência carregava.
  Pessoas bem-intencionadas criaram um site de notícias só em texto e, hoje, vi que o site do condado de Buncombe também ganhou uma versão de baixa largura de banda, mas, ao abri-la, ela ainda tinha 130 KB de CSS do Bootstrap e 50 KB de jQuery bloqueando a renderização.
  É ótimo que as pessoas estejam fazendo esse tipo de coisa, mas os cidadãos precisavam disso uma semana e meia atrás. Agora já descobrimos onde conseguir água, comida, água não potável etc. Passar por isso e ver a tecnologia falhar tão feio foi revelador de um jeito deprimente

  • Não chega a ser tão catastrófico, mas, nas quedas de energia do meu bairro, normalmente só resta o celular com sinal ruim. O equipamento da internet a cabo não tem energia de backup.
    O mapa de quedas da companhia de energia fica escondido atrás de login e é renderizado com clustering sofisticado e recursos de UI que já são lentos mesmo em uma conexão boa. Então até verificar o status ou informar uma queda leva bastante tempo.
    Também dá para ligar para a companhia de energia, mas eles escolheram navegação por voz em vez de tons do teclado, e o sistema não reconhece bem a voz distorcida por uma conexão 4G ruim ou 2G
  • Situações assim me fazem pensar em tirar de novo uma licença de rádio amador. Em um desastre como o que atingiu não só Asheville, mas uma área muito maior do oeste da Carolina do Norte, não quero depender de sistemas baseados na internet.
    São necessários comprimentos de onda longos e baixa potência. Mas a acessibilidade é muito baixa, e não tenho certeza se isso acontece por bons motivos.
    A conexão caiu de Black Mountain até as divisas com Tennessee e Georgia. Fico me perguntando se muita gente vai conseguir recuperar sequer aquele 3G ruim. O que sei é que foi difícil manter contato com as pessoas que moram lá
  • Tem link para o site de notícias só em texto?
  • Usei todo tipo de conexão ruim de internet por muito tempo, então estou acostumado com esse tipo de situação. Partes demais da internet são projetadas tendo em mente computadores rápidos, internet rápida e monitores excelentes.
    Alguns dos meus melhores trabalhos foram feitos em um MacBook de 12 polegadas conectado a um Wi‑Fi instável de hotel. Por isso me importo muito com velocidade de página
  • Moro em Sylva, a uns 45 minutos de Asheville, e foi realmente ruim tentar obter informações úteis pelo celular usando o serviço móvel. Se não fosse a Starlink, eu teria passado pelo menos uma semana sem saber nada sobre muitas coisas.
    Se eu tivesse que resumir a dor deste desastre em uma frase, seria colapso da comunicação de todos os tipos

• Concordo muito com a frase: “A web não pertence só a engenheiros de software. Quanto mais complexa tornamos a web, mais empurramos usuários comuns para dentro das cercas que chamamos de redes sociais”
  Há também um podcast relacionado à recente conferência Squiggle Conf, de onde veio essa citação: https://changelog.com/jsparty/339

• Com o tempo, as funcionalidades que as pessoas esperam de um “site básico” aumentaram bastante
  Mesmo sendo programador, eu também caí algumas vezes na armadilha dos geradores de sites estáticos
  É irritante começar um projeto paralelo com um gerador de site estático e, no momento em que quero adicionar uma pequena funcionalidade, me arrepender de não ter começado logo com uma aplicação simples em Rails ou PHP
  Hoje em dia, quando preciso de um site estático, simplesmente começo com uma pasta de arquivos HTML. O caminho da ideia à execução fica muito menos complicado e mais rápido, sem ficar debatendo ferramentas em teoria ou procrastinando
  Eu fico bem satisfeito escrevendo HTML e CSS diretamente, mas não recomendaria isso a todo mundo
  Outra coisa legal é que, se depois eu decidir “escapar” para Rails, basta copiar a pasta de arquivos HTML para a pasta public/ do Rails. O caminho de upgrade é bem fácil

  • Talvez você ainda não tenha encontrado o gerador de site estático adequado às suas necessidades
    No mundo Ruby, Jekyll é o mais conhecido, mas ele é voltado a um uso específico: escrever blogs em Markdown ou outra linguagem de marcação leve. Dá para forçar outros usos, mas como gerador de site estático de propósito geral ele não é tão confortável
    Se você quer algo fácil de copiar/colar para Rails, middleman, que é um gerador de site estático baseado em Rack, é bom. Dá para escrever desde o início com erb/haml e ActiveSupport
    Se quer manter a simplicidade de escrever HTML e CSS à mão, mas só ter conveniências como include, templates parciais e helpers de links, nanoc é uma boa opção como gerador de site estático incremental. Comece com HTML/CSS comum e adicione funcionalidades só quando precisar
  • Sem exemplos, fica difícil discutir. Comecei a usar Pelican há mais de 10 anos e ainda estou satisfeito
    De vez em quando escrevo código para personalizar o comportamento, mas é algo de uma vez a cada alguns anos. É simples e simplesmente funciona bem
    Há coisas de que sinto falta em sites dinâmicos, mas não sei bem em que sentido uma pasta simples de arquivos HTML seria melhor que Pelican
  • Tenho publicado no meu site pessoal há mais de 20 anos, e o fluxo foi mais ou menos HTML básico → Drupal → WordPress → HTML básico via Jekyll
    A regra básica que estabeleci para impedir o inchaço de funcionalidades do site foi definir a identidade que eu queria. Eu queria mantê-lo como um arquivo das coisas que fiz, e um arquivo precisa durar muito tempo. Por isso, arquivos estáticos, fáceis de copiar, espelhar e rodar em qualquer plataforma de hospedagem, fazem sentido
    Levou algum tempo para acertar bem um site multilíngue, mas pelo menos foi um custo pago uma única vez
  • Uso Hugo no blog. É porque fica mais fácil focar no conteúdo, não no estilo. É também por isso que não gosto de escrever arquivos HTML puros
    Mudanças de estilo também podem virar um problema se estiverem hardcoded nos arquivos HTML
    Para trabalhos mais avançados, escrevo em Django. Para mim, é muito fácil adicionar funcionalidades
  • Eu também, hoje em dia, quando preciso de um site estático, começo com uma pasta de arquivos HTML. Pensei em colocar uma etapa .md → .html para conteúdo, mas até agora não precisei
    Também é bom poder ver o site facilmente com um servidor local. O ideal seria que também desse para ver via file://, mas não consegui resolver totalmente a estrutura, então acabei com uma etapa make local que cria uma cópia separada para visualização baseada em arquivos

• Em sites pessoais de desenvolvedores web, há um fator que gera complexidade: o desenvolvimento orientado a currículo
  Há profissionais que querem usar projetos paralelos pessoais para desenvolvimento orientado a currículo, e acham que assim há menos chance de estragar os projetos do empregador
  Por exemplo, ainda hoje de manhã havia um site independente prestes a ser publicado e, principalmente por motivos de currículo, ele usava um framework web moderno e popular, mas acabou ficando impossível atualizar o site
  Havia uma vulnerabilidade crítica de segurança em um pacote NPM e, ao tentar atualizar, o NPM caiu em um conflito de interdependências que não conseguia resolver automaticamente. Ironicamente, por causa disso, não foi possível enviar a atualização de segurança para o site em produção
  Esse site poderia ter sido feito com 5 arquivos HTML escritos à mão, um pouco de JS inline e 2 pequenos scripts Perl CGI. Assim, ainda funcionaria perfeitamente depois de 25 anos
  Em vez disso, só a parte em NodeJS já tem 129 pacotes NPM, atualizações de segurança frequentemente necessárias e uma árvore obscura de arquivos-fonte composta por fragmentos de templates, configuração TS e handlers
  Mas profissionais não têm o luxo de não fazer as coisas de uma forma absurdamente complexa. Por exemplo, ter Perl no currículo é um golpe fatal para a empregabilidade. Mesmo as pessoas que não descartarem seu currículo por discriminação etária vão achar você idiota por não ter feito desenvolvimento orientado a currículo

  • Acho que a maré está mudando à medida que as pessoas começam a perceber a fragilidade da complexidade
  • Trabalho alternando entre web e sistemas distribuídos, mas felizmente um site PHP sem graça que lê conteúdo de arquivos XML e JSON nunca atrapalhou minhas mudanças de emprego
  • Você realmente tentou? E, se acha que não ajuda, não precisa colocar no currículo tudo que já fez até agora
  • 5 HTMLs escritos à mão, um pouco de JS inline e 2 Perl CGI podem funcionar perfeitamente por 25 anos, mas, por conveniência, também pode ser algo em algum ponto intermediário
    No meu caso, não tenho nenhum interesse em currículo ou propostas, mas ainda assim quero algo mais ergonômico do que cuspir HTML a partir de templates JS/Python. Por isso, meus sites são uma combinação de TypeScript, Mithril, Express e algumas bibliotecas utilitárias
    Não sei quantos pacotes são e nem me importo. Basta que as coisas que importo sejam maduras e não gerem um novo recurso-vulnerabilidade a cada poucos minutos
    Você não disse qual é a stack, mas parece bem provável que seja React e seu ecossistema de “sempre melhorando, mas nunca acabando”. Se posso dar um conselho não solicitado, é melhor não acreditar em uma falsa dicotomia. Há um grande espaço entre HTML puro e o pior lamaçal, e a situação do mundo React é específica do React, não representa tudo que existe fora dele

• O killer app do WordPress são os comentários. Geradores de sites estáticos quase por definição não permitem comentários, mas blogs em WordPress quase sempre os têm embutidos.
  Se algo como Hugo realmente quiser decolar no espaço de blogs, basta criar um tema bonito com comentários. É só resolver isso em escala. Por exemplo, usando SQLite particionado por blog, um terceiro poderia hospedar isso de forma muito barata. Aí vira uma pequena galinha dos ovos de ouro.

  • Isso fazia sentido na era dos blogs, mas acho que hoje é muito menos verdade.
    Comentários e discussões sobre textos ficam em comunidades de terceiros como Reddit, HN e Facebook. O que tem mais gente: quem percorre a lista de comentários abaixo de um post no Substack ou quem lê uma ou duas páginas de comentários do HN sobre o mesmo texto?
    Se for um texto sobre tecnologia, acho quase certo que a discussão no HN será de qualidade mais alta do que a cadeia de comentários de um post específico. Afinal, o HN já atraiu um público mais amplo do que 99,9% de todos os blogs.
    A principal vantagem de comentar diretamente em um post de blog é apenas que a chance de o autor ver é muito maior. Ficar por um breve momento na primeira página do HN é efêmero.
  • O Hacker News e os “programadores de verdade” continuam subestimando os conceitos básicos de um CMS. Como consideram isso uma tecnologia sem graça, tratam todos os problemas ao redor dela como problemas chatos que já foram resolvidos e, por isso, não sabem bem quais são os problemas reais.
    O ecossistema do WordPress é o oposto. Ele reúne negócios de bilhões de dólares que entendem profundamente o que pessoas que operam CMSs e sites precisam em seus pequenos nichos de mercado, e esse mercado tem algo como 500 milhões de sites.
    A pessoa que escreveu este texto pode até ser inteligente, mas claramente não é inteligente sobre os usos práticos de um CMS. A visão de mundo de que “sites em HTML estático são melhores, mas não são populares por causa de empresas malignas” se revela quase errada assim que você cria um ou dois sites pagos.
    Geradores de sites HTML estáticos quase nunca conseguem fazer tudo que o cliente quer. O WordPress percebeu há muito tempo o quão amplo e diverso esse mercado é, e por isso implementou suporte a plugins.
    Concordo 100% que comentários são um dos usos originais, na web, para algo mais próximo de um CMS em vez de um gerador de site estático. Mas há também um milhão de outros usos.
    Só com documentos HTML estáticos não se vai muito longe. Quando você sai de um blog minimalista de desenvolvedor, é preciso bastante lógica de programa para fazer o que usuários e clientes reais querem. Então você usa um CMS adequado às suas necessidades e, se precisar aguentar muito tráfego, faz cache agressivo. Isso também faz parte do trabalho.
    Eu simplesmente não entendo por que desenvolvedores que se acham incríveis tentam reinventar a roda em vez de aprender um pouco sobre como cache funciona e aplicar isso. Será que isso também é um “problema resolvido” chato demais?
  • O killer app do WordPress não são os comentários, e sim o ecossistema de plugins. Há plugins que, no WordPress, até sua mãe consegue ativar com dois cliques, enquanto no Hugo você passaria o fim de semana inteiro configurando.
    Eu também uso Hugo, mas, embora do ponto de vista de engenharia a pegada do WordPress seja desnecessariamente grande, a experiência do usuário é muito mais amigável.
  • Outro elemento de “interação” são os formulários de contato.
    Nem todo site de negócio quer comentários, mas provavelmente quer um formulário de contato. Publicar um endereço de e-mail também é uma alternativa, mas é melhor lidar com um pipeline de entrada.
    Em um site estático, você precisa encontrar um serviço confiável para processar os envios e integrá-lo corretamente ao site. Isso cria mais uma peça móvel, pode virar mais uma fatura a pagar e adiciona mais um elemento para lidar quando o setor passa por consolidação.
  • O Disqus resolveu isso por um tempo, mas ao longo dos anos tem feito coisas que afastam as pessoas: https://en.wikipedia.org/wiki/Disqus#Criticism,_privacy,_and...
    https://hn.algolia.com/?q=%22disqus%22
    O Facebook também oferecia um sistema de comentários usado por muitos sites, mas perdeu confiança e alcance após vários escândalos.

• Eu também me encaixo nesse paradoxo. Reescrevi meu site pessoal em PHP moderno, sem framework nem banco de dados.
  É um site majoritariamente estático, mas uso PHP para adicionar o cabeçalho e lidar com listas, como a lista de posts do blog. Ser não totalmente estático foi um pouco mais conveniente. Escrevo um post, faço commit, push, e ele entra online na hora. A maioria dos geradores de sites estáticos me parecia complicada demais.
  O código de uma página individual é mais ou menos algo como title = "Blog Article Title";, $this->shortTitle = "Title";, $this->date = mktime(0,0,0,1,27,2024);, if ($this->mode == PageMode::Meta) return;, seguido do conteúdo HTML bruto.
  O roteador adiciona automaticamente o cabeçalho e o rodapé do site, e, se eu acrescentar um arquivo _layout.php a uma pasta, consigo aplicar mais um nível de layout às subpáginas. A página de listagem do blog percorre os arquivos de posts individuais na pasta e cria um índice.
  É aí que $this->mode == PageMode::Meta é usado. Ele executa o código de cada arquivo para obter os metadados e sai antes de renderizar o restante. Se houver muito conteúdo, isso não vai escalar muito bem, mas, se virar um problema, ajustarei.
  Todo o código PHP do meu “framework” se resume a quatro arquivos: init.php, functions.php, Layout.php e Page.php.
  A vantagem de ser desenvolvedor é poder usar código em vez de configuração ou dados. Também dá para usar código para escrever conteúdo de forma mais eficiente.
  O resultado ainda está bem inacabado, mas está aqui: https://www.codaris.com/

  • Um dos meus sites acabou de começar do mesmo jeito. 90% é HTML, e uso PHP só para include() do cabeçalho e de alguns fragmentos globais.

• Pensando na experiência do usuário do ponto de vista do dono do site, isso não é bem um paradoxo. O WordPress torna as coisas absurdamente fáceis, mesmo tendo um overhead muito maior
  Só parece um paradoxo quando se pensa nisso como um trade-off em relação a gastar tempo configurando várias coisas. Para a maioria das pessoas, a alternativa é pagar alguém para criar o site
  Se você criar um editor WYSIWYG para Hugo e fizer com que tudo, do registro do domínio à publicação do site, seja resolvido em poucos cliques, dá para ganhar muito dinheiro

  • Não é isso que empresas como Netlify, Squarespace e GitHub Pages fazem? No Netlify, você transfere um domínio estacionado, escolhe um template, e ele cuida da maior parte da configuração; o site fica no ar em poucos minutos, e o tratamento do domínio leva cerca de 24 horas
    Entendo o que você quer dizer. Mesmo que essas empresas cheguem perto do que foi dito, se alguém conseguir cuidar das pequenas etapas intermediárias, isso seria uma grande vantagem para alguém
  • Você não acabou de descrever o Micro.blog[1]?
    [1] https://micro.blog

• O trecho “Quando lancei o SuperHTML, percebi que era o primeiro servidor de linguagem para HTML a reportar diagnósticos ao usuário. Escrevi um post no blog, ele chegou à primeira página do Hacker News, e ninguém me corrigiu, então é verdade” provavelmente se deve ao fato de que a maioria das IDEs já fazia isso havia anos, antes mesmo de a Microsoft lançar o LSP

  • Acho que havia pouquíssimos editores populares com uma forma de fornecer diagnósticos para HTML puro. A única exceção que conheço é o WebStorm
    Vim, Neovim, Helix, Zed e VSCode compartilhavam todos a mesma implementação básica, sem suporte a diagnósticos
    O Helix pretende habilitar o SuperHTML por padrão a partir da próxima versão: https://github.com/helix-editor/helix/pull/11609