Parecer: melhor SSG minimalista para entrar no no-js.club

Compilado por Pablo Murad — 2026
Data da pesquisa: 17/06/2026
Objeto: escolher, entre os SSGs da lista anterior, o melhor candidato para criar um site compatível com o no-js.club, priorizando leveza real do site final e customização.

Resumo brutal

O melhor encaixe geral é mkws.

O mais leve absoluto, se o critério for “menor gerador + menor HTML possível + quase nada de abstração”, é ssg.sh / ssg5.

Mas, se a pergunta completa é: “quero o mais leve e o mais customizável para um site no espírito no-js.club”, o vencedor prático é:

mkws — porque é pequeno, não injeta JavaScript, trabalha como pipeline Unix, usa sh como mecanismo de template e deixa você controlar o HTML final quase no osso.

Minha decisão final:

A resposta preguiçosa seria “qualquer SSG serve, é só não colocar JS”. Tecnicamente sim. Mas isso é superficial. O SSG certo para o no-js.club precisa te impedir de cair em tentação: nada de busca client-side, nada de analytics, nada de comentários de terceiros, nada de tema que injeta script, nada de SPA disfarçada.

O que o no-js.club exige de verdade

Pelo repositório oficial do no-js.club, o requisito central é simples:

1. O site precisa usar zero JavaScript.
2. Você deve procurar por tags <script> na página.
3. Deve rodar um scan no GTMetrix.
4. Se estiver limpo, envia uma issue no GitHub para inclusão.

Fonte: https://github.com/karan/nojs.club/blob/main/README.md

Isso muda a régua. O importante não é a linguagem do SSG. Um SSG escrito em JavaScript pode gerar HTML sem JavaScript no cliente. Mas, para este caso, eu penalizo ferramentas que carregam ecossistema pesado, temas com busca client-side, analytics, hidratação, assets mágicos ou qualquer recurso que incentive script no navegador.

Critérios usados neste parecer

Eu avaliei os SSGs em seis eixos:

Importante: “mais leve” pode significar duas coisas diferentes:

• Leveza do gerador: tamanho do programa, dependências, linguagem, instalação.
• Leveza do site final: HTML/CSS gerado, ausência de JS, ausência de assets supérfluos.

Para entrar no no-js.club, o que mais importa é a segunda. Para você estudar/criar seu próprio SSG, a primeira também importa.

Shortlist real: os candidatos que valem a briga

1. mkws — vencedor geral

Link: https://mkws.sh/

Por que encaixa melhor:
O mkws é quase a ideia perfeita para um site no-js: geração estática como pipeline Unix, template em sh, HTML sob seu controle e zero obrigação de JavaScript. A documentação e análises públicas descrevem o projeto como pequeno, hackeável e extensível com qualquer utilitário Unix.

Pontos fortes:

• Não injeta JavaScript por padrão.
• Usa HTML/template sob controle direto.
• Customização via shell é poderosa.
• Filosofia combina com site artesanal, leve e audível.
• Bom para quem quer entender o pipeline inteiro.

Pontos fracos:

• Template em shell é poderoso, mas não é confortável para todo mundo.
• A curva mental é maior que makesite.py ou staticjinja.
• Pode virar gambiarra se você não impuser limites.

Veredito:
É o melhor equilíbrio entre leveza e customização. Se a ideia é criar um site “clube no-js” com personalidade própria, sem engine inchada, eu iria de mkws.

2. ssg.sh / ssg5 — o mais leve absoluto

Links:
https://romanzolotarev.com/ssg/
https://github.com/fmash16/ssg5

Por que é fortíssimo:
O ssg.sh é um script POSIX shell de cerca de 12 KB, com dependência opcional no lowdown. Ele converte Markdown para HTML, aplica templates simples, copia arquivos e gera sitemap/robots. Isso é praticamente a definição de SSG mínimo.

Pontos fortes:

• Extremamente leve.
• Output HTML direto.
• Não tem frontend mágico.
• Fácil de auditar.
• Excelente para páginas simples, manifesto, blog pequeno ou site pessoal.

Pontos fracos:

• Customização é mais limitada que mkws.
• O próprio autor alerta que ele lê/escreve no destino e pode apagar arquivos inesperados.
• O modelo header/footer é simples demais se você quiser layouts mais sofisticados.

Veredito:
Se sua pergunta fosse apenas “qual é o mais leve?”, eu responderia ssg.sh / ssg5. Mas como você pediu leve e customizável, ele perde por pouco para mkws.

3. makesite.py — melhor hackabilidade em Python

Link: https://github.com/sunainapai/makesite

Por que entra na final:
O projeto se define como um gerador Python simples, leve e “magic-free”. O README deixa claro que a ideia é você controlar tudo: o código é a documentação, o código é a configuração, e o núcleo tem menos de 130 linhas relevantes.

Pontos fortes:

• Excelente para estudar e modificar.
• Python é mais legível que shell para muita gente.
• Não injeta JS por padrão.
• Layout, CSS e conteúdo ficam explícitos.
• Ótimo ponto de partida para criar seu próprio SSG.

Pontos fracos:

• Não é tão minimalista quanto ssg.sh no sentido Unix puro.
• Se você começar a adicionar features, vira framework caseiro rápido.
• Customização exige mexer em Python, não apenas em templates.

Veredito:
Se você quer criar um SSG seu para o Murad Press/Murad Library, este talvez seja o melhor “código-escola”. Para simplesmente entrar no no-js.club com máxima leveza, mkws/ssg.sh são mais alinhados.

4. staticjinja — melhor opção pragmática com templates bons

Link: https://github.com/staticjinja/staticjinja

Por que é bom:
É uma biblioteca minimalista para gerar sites estáticos com Jinja2. O projeto se apresenta como leve, com menos de 500 linhas de código-fonte, fácil de usar, aprender e estender.

Pontos fortes:

• Jinja2 é muito confortável.
• Boa separação de templates e conteúdo.
• Customização alta sem inventar DSL esquisita.
• Não precisa gerar JS nenhum.

Pontos fracos:

• Mais dependência que shell puro.
• Menos “clube raiz” que mkws/ssg.sh.
• Não é uma engine de blog completa.

Veredito:
Escolha racional se você quer customização limpa e não quer sofrer com shell. Não é o mais leve, mas é bem controlável.

5. Soupault — mais poderoso, mas não o mais leve

Link: https://soupault.net/

Por que considerar:
Soupault trabalha reescrevendo a árvore HTML. Isso é brilhante para site artesanal: você escreve HTML simples e deixa o Soupault inserir sumário, metadados, navegação, listas e outros elementos no build, sem JS no cliente.

Pontos fortes:

• Muito customizável.
• Pode substituir coisas que muita gente faria com JS no navegador.
• Excelente para pós-processar HTML artesanal.
• Bom para sites literários, zines, documentação e páginas longas.

Pontos fracos:

• Não é o mais leve mentalmente.
• É mais framework/ferramenta de processamento do que script minimalista.
• Para um site pequeno, pode ser ferramenta demais.

Veredito:
Ótimo se você quer automações HTML avançadas sem JS. Mas para “mais leve”, perde.

6. Sergey — bom conceito, mas eu evitaria para este caso

Link: https://sergey.trysmudford.com/

Por que aparece:
Sergey é HTML + partials + slots. Conceitualmente é ótimo para no-js, porque ele parte do seu HTML e só resolve includes/slots.

Pontos fortes:

• Muito bom para sites HTML simples.
• Partials e slots resolvem 80% do problema de manutenção.
• Não precisa gerar JS no cliente.

Pontos fracos:

• Roda no ecossistema Node/npm.
• O próprio site fala que ele ainda está em infância.
• Para o espírito no-js.club, Node não é proibido, mas é uma camada desnecessária se mkws/ssg.sh resolvem melhor.

Veredito:
Bom, mas não é minha escolha para “mais leve”.

7. Marmite — bom SSG moderno, mas cuidado com busca

Link: https://marmite.blog/

Por que é tentador:
Marmite é moderno, Rust, single binary, focado em blog Markdown, com RSS, live reload e configuração simples.

Problema para no-js.club:
A documentação mostra opção de --enable-search true. Busca client-side frequentemente implica JavaScript. Mesmo que seja opcional, isso já é uma zona de risco para o objetivo no-js.

Veredito:
Bom para blog moderno leve. Mas, para entrar no no-js.club, eu usaria só com busca desativada e inspecionaria o HTML final.

8. bashblog — leve, mas blog demais

Link: https://github.com/cfenollosa/bashblog

Por que é forte:
É literalmente um script Bash para criar blogs. Sem instalação pesada, sem banco, sem CMS.

Problema:
Ele é opinativo para blog. Além disso, tem suporte a coisas como Disqus, Twitter, Feedburner e Google Analytics — recursos que normalmente quebram a ideia no-js se ativados.

Veredito:
Pode entrar no no-js.club se usado de forma limpa. Mas eu não escolheria se o site for mais editorial/customizado do que blog cronológico.

Ranking final para o objetivo específico

Parecer sobre os 50 da lista anterior

Esta não é uma auditoria linha-a-linha de código de todos os 50. Seria falso vender isso. É uma triagem técnica por adequação ao objetivo no-js + leveza + customização, usando a lista anterior como universo inicial.

Minha recomendação operacional

Use mkws se você quer um site com estética própria, HTML limpo, CSS artesanal e possibilidade de customizar o pipeline.

Use ssg.sh / ssg5 se você quer o mínimo possível e aceita um modelo simples de header/footer.

Use makesite.py se sua intenção real é criar seu próprio gerador em cima de algo legível.

Para o seu caso, especialmente se a ideia for algo próximo de Murad Press/Murad Library, zine, biblioteca, ensaio, páginas editoriais e HTML artesanal, eu escolheria:

mkws como ferramenta principal
ssg.sh como referência de minimalismo extremo
makesite.py como referência didática para um SSG próprio

Como eu montaria para passar no no-js.club

Estrutura sugerida:

site/
  index.upphtml
  about.upphtml
  posts/
    primeiro-post.upphtml
  share/
    layout.upphtml
    head.upphtml
    nav.upphtml
    footer.upphtml
  static/
    style.css
    fonts/        # opcional; cuidado com peso
  dist/

Regras de ouro:

1. Não usar <script> em nenhuma página.
2. Não usar analytics.
3. Não usar Disqus, comentários externos ou embeds sociais.
4. Não usar busca client-side.
5. Não puxar fonte de CDN.
6. CSS local, pequeno e auditável.
7. Imagens otimizadas.
8. HTML final inspecionado com grep -R "<script" dist/.
9. Rodar GTMetrix antes de submeter.
10. Usar RSS estático se quiser distribuição, não JS.

Checklist:

grep -R "<script" dist/ || echo "OK: nenhum script encontrado"
grep -R "javascript:" dist/ || echo "OK: nenhum javascript: encontrado"
grep -R "googletagmanager\|google-analytics\|plausible\|umami\|disqus" dist/ || echo "OK: sem trackers comuns"

Arquitetura recomendada

HTML

Use HTML semântico simples:

<header>
  <h1>Nome do site</h1>
  <nav>
    <a href="/">Início</a>
    <a href="/sobre.html">Sobre</a>
    <a href="/arquivo.html">Arquivo</a>
  </nav>
</header>

<main>
  <article>
    <h2>Título</h2>
    <p>Texto...</p>
  </article>
</main>

<footer>
  <p>Feito por Pablo Murad — 2026</p>
</footer>

CSS

Use CSS local e pequeno. Não precisa framework.

:root {
  --bg: #f8f0dc;
  --ink: #111;
  --accent: #ff6f61;
}

body {
  margin: 0 auto;
  max-width: 72ch;
  padding: 2rem 1rem;
  background: var(--bg);
  color: var(--ink);
  font: 18px/1.6 system-ui, sans-serif;
}

a {
  color: inherit;
  text-decoration-thickness: .12em;
}

Recursos no-js que substituem JS

Veredito final

Escolha final: mkws.

Motivo: é o que melhor combina leveza, controle total do HTML, customização real, ausência natural de JavaScript e filosofia compatível com no-js.club.

Mais leve puro: ssg.sh / ssg5.

Motivo: script shell minúsculo, modelo direto e output extremamente simples.

Melhor base para criar seu próprio SSG: makesite.py.

Motivo: código pequeno, Python legível e filosofia “código é configuração”.

Se eu tivesse que reduzir a decisão a uma frase:

Para entrar no no-js.club com um site bonito, artesanal, leve e hackeável, use mkws; estude ssg.sh para não engordar; copie ideias de makesite.py se decidir criar seu próprio gerador.

Fontes consultadas

• no-js.club README — https://github.com/karan/nojs.club/blob/main/README.md
• no-js.club site — https://no-js.club/
• ssg.sh — https://romanzolotarev.com/ssg/
• ssg.sh repositório/atividade — https://got.romanzolotarev.com/?action=summary&path=ssg.git
• ssg5 artigo — https://fmash16.github.io/content/posts/ssg5_site.html
• mkws — https://mkws.sh/
• mkws review LinuxLinks — https://www.linuxlinks.com/mkws-simple-static-site-generator/
• makesite.py — https://github.com/sunainapai/makesite
• staticjinja — https://github.com/staticjinja/staticjinja
• Soupault — https://soupault.net/
• Sergey — https://sergey.trysmudford.com/
• Marmite — https://marmite.blog/docs.html
• bashblog — https://cfenollosa.github.io/bashblog/
• Jamstack Generators — https://jamstack.org/generators/