Blog mínimo viável (Minimum viable blog)

(ostwilkens.se)

6 pontos por GN⁺ 2025-05-04 | 5 comentários | Compartilhar no WhatsApp

O objetivo é criar um blog pessoal como páginas estáticas em um domínio já existente, com uma implementação mínima que também satisfaça a adição de conteúdo e SEO básico
A implementação segue de forma simples com um pequeno template.html, markdown2, um render.py criado a pedido pelo O1 e redação de posts em Markdown
O template usa apenas HTML/CSS básico, como system-ui, largura máxima de 70ch, color-scheme: light dark, viewport e UTF-8
O render.py converte ./posts/{post}/eng.md para HTML, ajusta os caminhos das imagens e então gera ./blog/{post}.html e index.html
Mostra que é possível criar um blog operável apenas com renderização estática e hospedagem, sem Jekyll, Ghost ou WordPress

Requisitos mínimos do blog e configuração real

O ponto de partida eram quatro requisitos
- Usar um domínio já possuído
- Seguir padrões modernos da Web e ter um SEO razoável
- Tornar muito fácil adicionar novo conteúdo
- Todas as páginas serem compiladas estaticamente
O fluxo real de implementação é simples
- Escrever um pequeno template.html
- Executar pip install markdown2
- Pedir ao O1 um script render.py
- Escrever o post, renderizar e hospedar
Não são usados motores de blog existentes como Jekyll, Ghost ou WordPress

Template e script de renderização

O template.html contém apenas a estrutura básica de um documento HTML e um mínimo de CSS
- Define o esquema de cores claro/escuro com color-scheme: light dark
- O estilo do corpo é configurado com system-ui, sans-serif, largura máxima de 70ch, altura de linha 1.5 e tamanho de fonte 1.25em
- Usa um link para a home com id="head-link" e o placeholder {{ content }}
O render.py converte posts em Markdown para HTML com markdown2
- O diretório de entrada é ./posts e o diretório de saída é ./blog
- Cada post é lido de ./posts/{post_directory}/eng.md
- O primeiro cabeçalho # é usado como título do post
- Converte o Markdown com as opções fenced-code-blocks e header-ids
- Altera o <img src=" dos caminhos de imagem para ter como base /posts/{post_code}/
- Substitui o {{ content }} do template pelo HTML convertido e também troca a string do título pelo título do post
A página de índice também é gerada pelo mesmo script
- Primeiro converte greetings.md para HTML
- Lê o título de cada post e adiciona uma lista de links para /blog/{post_code}.html
- Salva o resultado final como index.html
O post foi escrito manualmente em 2025-03-31

5 comentários

ifmkl 2025-05-07

Eu também estou mantendo meu blog atualmente exatamente desse jeito. Estou usando um SSG que criei para atender às minhas necessidades pessoais. Para aproveitar recursos como imagem de miniatura, categoria e tags, adicionei funcionalidades personalizadas separadamente. As imagens anexadas são convertidas automaticamente para webp para serem referenciadas, e graças a isso a velocidade de renderização está muito satisfatória.

winterjung 2025-05-07

Ah, então esses recursos personalizados você vai adicionando aos poucos escrevendo o código por conta própria? Eu também sempre penso em fazer tudo no estilo DIY, mas acabo hesitando por causa das extensões e plugins que os frameworks de blog SSG que eu já usava oferecem.

ifmkl 2025-05-07

Se você deixar a ambição de lado — só isso — o resto não é tão difícil. Até no SSG, se você pedir para a IA, ela escreve todo o código, e se pedir para adicionar funcionalidades, na verdade ela adiciona tudo também haha

ndrgrd 2025-05-04

Se você escolher só uma fonte bonita, já fica bem agradável de ler.

GN⁺ 2025-05-04

Opiniões no Hacker News

Isso me lembra o gráfico deste post de blog: https://molodtsov.me/2023/02/how-to-start-your-blog-in-2023/
Quando caí no pântano dos geradores de sites estáticos (SSG), acabei passando a maior parte do tempo escrevendo sobre e mexendo no próprio SSG, em vez de escrever os textos que eu queria ou fazer o que pretendia
No fim, larguei o SSG, instalei o WordPress e parei de me preocupar; foi uma grande sensação de libertação
Se o objetivo é fuçar e escrever sobre esse processo, tudo bem; e também tudo bem para quem consegue fuçar sem que isso atrapalhe a escrita, mas não era o meu caso
A última coisa de que você precisa no momento em que vai escrever é uma desculpa para adiar
- O WordPress em 2025 combina duas características perigosas
  O WordPress e todos os plugins podem ser comprometidos se não forem mantidos atualizados, e o BDFL é alguém que pode bloquear a entrega de atualizações de segurança ou o acesso para recebê-las por motivos pessoais triviais
  Sites estáticos não têm vulnerabilidades de segurança a serem corrigidas, então mesmo que um projeto de SSG desmorone completamente por problemas com o mantenedor, isso não faz tanta diferença; mas no WordPress isso se torna muito importante
- Comigo foi parecido. Muito tempo atrás comecei com DokuWiki, depois resolvi experimentar o GitHub Pages e, depois de migrar tudo, precisei de busca, então adicionei uma busca personalizada do Google
  Precisava de um jeito para visitantes deixarem comentários, então adicionei o Disqus, e no fim virou uma mistura confusa de vários serviços e muito JavaScript
  Alguns anos atrás, para voltar a ser dono dos meus dados e não depender de serviços externos, exportei os comentários do Disqus, mexi no Serendipity e acabei ficando com o WordPress
  Consegui importar comentários e páginas em Markdown, e também havia um plugin que publicava tudo no Fediverse
  Fiz funcionar com SQLite e deixei as atualizações automáticas ligadas, então praticamente não exige manutenção
- Spam de blog? :) A URL é https://rakhim.org/honestly-undefined/19/
- Concordo, mas acho que em 95% dos casos o WordPress é exagero
  Ele exige manutenção demais por causa de funcionalidades de que provavelmente você não precisa. Se você não o mantiver atualizado, pode virar parte de uma botnet
  Para a maioria dos blogs, um gerador de site estático é suficiente, e qualquer manutenção necessária pode ser feita quando eu quiser
- Estou bastante satisfeito com o nikola: https://getnikola.com/
  O que eu realmente queria era um único comando para publicar e uma forma fácil de arrastar e soltar imagens nos posts; o primeiro funciona bem, e o segundo é possível com o recurso de publicação de Jupyter Notebook
  O que eu definitivamente não queria era um modelo em que “enviar HTML ao cliente” viesse com o peso de um banco de dados
Gostei, mas sinto que, para chamar de blog, faltam mais duas pequenas funcionalidades
Primeiro, os posts precisam ser ordenados por data, com os mais recentes primeiro, e a data precisa aparecer em algum lugar. Para manter a configuração mínima, dá para usar metadados do arquivo do post, por exemplo o horário de criação
Segundo, obviamente é preciso ter um feed RSS. Só com o script existente e um template RSS mínimo, deve ser fácil criar um feed simples contendo apenas links e títulos
- RSS é bom, mas acho que não deveria ser requisito obrigatório para algo ser reconhecido como blog
  Ser “seguido” nem sempre é algo bom e pode criar pressão para agradar aos leitores. É exatamente isso que torna as redes sociais ruins
- Faz sentido
  Para o item 1, estou inclinado a gerar automaticamente um arquivo com metadados em algum formato como TOML
  Quanto ao item 2, RSS, com certeza vou adicionar, mas ele depende do item 1 :-)
Sempre gostei de sites independentes, e o meu também começou de forma parecida há cerca de 25 anos
Na época, a única tecnologia adequada que eu conhecia era Classic ASP, então fiz algo simples, com uma configuração mínima, só em ASP
Hoje ele roda como um site gerado estaticamente em Common Lisp, e acho que essa configuração será a de longo prazo: https://github.com/susam/susam.net/blob/main/site.lisp
Começar com um conjunto simples de páginas foi uma boa maneira de criar um site minimamente viável, mas, com o tempo, passei a precisar de recursos como feed RSS, lista de posts do blog em ordem cronológica, índice por tags, suporte a conteúdo que não é de blog, como ferramentas, jogos e demos, e comentários sem terceiros
A cada novo requisito, o código-fonte também cresceu: de algumas centenas de linhas, agora virou cerca de 1300 linhas de Common Lisp
Mesmo assim, quero mantê-lo em um nível em que eu consiga ter o código inteiro na cabeça de uma vez e, quando surgir um bug, consiga raciocinar sobre ele e corrigi-lo em até 10 minutos
Hoje em dia tenho a tentação de adicionar um blogroll que ofereça uma lista de posts dos meus blogueiros favoritos. Talvez até possa substituir um leitor de feeds, mas tento tomar cuidado para que isso não cresça a ponto de virar algo que também lê e-mails
- Segui quase o mesmo caminho
  O código-fonte está aqui: https://github.com/brilee/modern-descartes-v2/blob/master/ma...
  Inclui feed RSS, lista de posts do blog em ordem cronológica, sistema de tags e um servidor de desenvolvimento local com recompilação por monitoramento de arquivos
- Meu caminho também foi parecido e, na verdade, já repeti isso algumas vezes
  A versão atual é mantida como um script Python com menos de 1000 linhas: https://github.com/llimllib/obsidian_notes/blob/c93b9b5c46fe...
- É exatamente isso. A capacidade de decidir “quero criar este dispositivo” e codá-lo você mesmo é melhor do que qualquer WYSIWYG
  Criei páginas derivadas, como conjuntos de posts, índices e slideshows, além de variações de tags para pessoas e videogames
  Também dá para controlar totalmente a aparência e a sensação de widgets comuns, como galerias de miniaturas ou caixas de citação
- Criei no Lamb um recurso chamado Flock, que faz a sindicação de feeds para o meu blog. Fiz principalmente como uma alternativa em estilo multiusuário: https://github.com/svandragt/lamb
  Pode servir como uma referência de alto nível
- RSS e datas certamente parecem necessários
  No futuro, talvez eu queira incorporar shaders e jogos web também, mas espero que a complexidade não aumente demais
Seria bom se os navegadores oferecessem suporte nativo a text/markdown e text/gemini
Se o navegador consegue renderizar PDF, não parece tão difícil incluir um formatador simples para conteúdo Markdown/Gemini e uma stylesheet que o usuário possa definir
Mesmo hoje dá para escrever um blog em text/plain, mas isso não é hipertexto de verdade e prejudica o SEO. Talvez dê para fazer alguma mágica com o header link
Suportar outros formatos reduziria a barreira para publicar de forma limpa e devolveria o controle ao usuário
- Renderização de Markdown nativa no navegador seria legal, mas infelizmente parece improvável
  Primeiro os navegadores teriam de chegar a um acordo sobre qual variante e quais extensões de Markdown usar. Markdown é quase o CSV dos formatos de texto, porque todo mundo usa do seu próprio jeito
  Se for minimalista demais, haverá reclamações de que é inútil; se escolherem extensões, haverá reclamações de que ficou inchado
  Mesmo uma discussão cuidadosa sobre prós e contras de curto e longo prazo pode ser bloqueada com o argumento de “não deixe o perfeito ser inimigo do bom”
  Mesmo que cheguem a um acordo sobre um conjunto específico de recursos, também fica a dúvida se isso realmente valeria a pena
  Ler PDFs diretamente no navegador é algo bastante comum, mas os benefícios de ler Markdown diretamente provavelmente iriam apenas para uma parte dos desenvolvedores de software do mundo e umas cinco pessoas esquisitas
  Por isso, não ficaria surpreso se eu não visse renderização nativa de Markdown nos navegadores durante a minha vida
- A renderização de PDF no navegador foi feita em JavaScript, ou pelo menos foi em algum momento
  Também existem bibliotecas para XSLT que podem ser usadas quando é preciso uma versão mais nova do que o suporte nativo do navegador, e há bibliotecas para vários formatos, como jpegxl
- O Gemini também tem um formato próprio?
Se for html_content = html_content.replace('Minimum viable blog', title), então toda vez que a string Minimum viable blog aparecer no texto ela é trocada pelo título atual do post? Isso não é um bug?
- Sim, boa observação
  O código no post era o primeiro rascunho criado pelo O1, e essa string foi substituída por {{ title }}
Venho experimentando blogs minimalistas há cerca de 15 anos e aprendi alguns truques
Algo como const title = lines.match(/# (.+)/)[1] já é suficiente, então dá para evitar frontmatter
Meus blogs nunca tiveram posts demais a ponto de precisarem de paginação, tags, categorias ou ordenação
JSX é bem bom como um builder de strings puramente server-side se você usar algum hack suspeito como https://immaculata.dev/guides/enabling-jsx.html
Agora também ficou fácil usar etapas de build arbitrárias no GitHub Pages em vez do Jekyll, com algo como https://immaculata.dev/guides/using-gh-pages.html
highlight.js é praticamente o rei do realce de sintaxe de código extremamente fácil, bastando adicionar três linhas ao HTML, e shiki é bonito, mas lento
É fácil usando frameworks padrão de blog estático, como Hugo/Zola + Cloudflare Pages
Meu blog também tem uma configuração mínima, com menos de 100 KB, e atende a todos os critérios listados pelo autor do texto original
Uso o tema Hugo Blog Awesome, sigo as diretrizes de 512kb, verifiquei o tamanho das páginas e removi imagens e JS desnecessário. Para começo de conversa, não havia muita coisa
Referências: https://512kb.club, https://radar.cloudflare.com/scan
Mantive um “MVB” por um tempo, mas o meu era ainda mais simples
Eu simplesmente tinha uma única página HTML, escrevia os posts como arquivos .txt e atualizava a homepage manualmente
Era bem verboso, mas ainda assim acho que era mais fácil do que lidar com a web moderna
Depois migrei para algo mais sofisticado e agora uso Astro no meu site pessoal e blog, e ele é realmente excelente
Na landing page, o Astro afirma ser a melhor plataforma para “sites centrados em conteúdo” e, depois de 6 meses usando, passei a concordar
Ele oferece convenções claras e fáceis de seguir para quase tudo que é necessário para criar um blog, e elimina o que é dispensável
- Astro é realmente incrível. Não entendo por que não é mais popular
- Fico curioso se você usa o tema de outra pessoa ou se criou o seu próprio
Experimentei em alguns sites uma abordagem com Bun JS e HTML dentro de strings JavaScript
O Bun tem uma flag —hot que regenera o HTML estático quando há mudanças
O IntelliJ IDE detecta o comentário // language=html acima da string e também formata e destaca a sintaxe do HTML interno
Usar funções JavaScript puras em vez de uma linguagem de template permite escrever diretamente a lógica necessária, sem precisar procurar como fazer isso na linguagem de template
Cansado de sites tão inchados que demoram para carregar, estou usando uma abordagem muito parecida no meu blog: https://blog.borrego.dev
Fonte: https://github.com/agubelu/blog
- Gostei muito, e ele é bonito. Como fica no celular?