Orion vs. Hugo

[VERIFICADO] Última atualização por Joe Schaefer em dom, 28 jun 2026    origem

 

Orion now has better Twitter integration than Hugo, and it's not even close:https://t.co/7WBeP73Md0

— SunStar Systems (@sunstarsys) June 27, 2026

Prefácio

Eu entendo que as comparações tecnológicas são um tabu religioso em muitos círculos. O ponto principal que eu estou tentando transmitir é que enquanto Orion é anunciado como um Enterprise Jamstack Wiki, ele tem muitos casos de uso viáveis fora desse domínio de problema específico.

No entanto, a essência deste artigo é representar o SSG licenciado pela Apache da Orion como um SSG melhor do que o Hugo para você e suas equipes de engenharia de software. Tem mais potência, mais desempenho, mais recursos principais e muito mais fácil de personalizar. Além disso, é bem documentado e tem potencial ilimitado para verdadeiros usuários de poder lá fora, assim como você!

@SunStarSys/orion

• NKOTB

• Opinião com Curva de Aprendizagem Gradual

@GoHugoIo/hugo

• Popular

• Temas e extensões de terceiros robustos

• Opinião c/ Curva de Aprendizagem Profunda

Conjuntos de Recursos Comuns

• Apache Licenciado

• Alto Desempenho (velocidade máxima de processamento de documentos em ~1K documentos por segundo)¹

• Gerenciamento de Dependência em Cache

• Modelo de segurança sofisticado

Orion como Hugo++

1. (Configurável) Poder total de Django Templates dentro de fontes Markdown

2. Fluxo de Controle Robusto, Construções For-Loop e Filtros Django

3. Acesso Total a documentos anexados YAML/CSV como estruturas de dados

4. Gráficos de Vetor ativados para WebGL²

5. Agregar Operações de Vetor em Dados de Tabela por meio de PDL

6. ssi ignora cabeçalhos de arquivo

7. Negociação de Conteúdo / MultiViews

8. Fácil de usar

9. Builds Incrementais Flexíveis e Verdadeiros

10. ACL por arquivo/diretório (também conhecida como refinada), incluindo controles na pilha de software do build e na própria configuração

11. Robusto $\KaTeX$ Suporte

12. Pesquisa de PCRE integrada

Casos de Uso do Editor de CMS do Orion

1. Linting de Upload de Documento com base no tipo MIME (Markdown, Perl, YAML, CSV, $\LaTeX$)

2. Validação/Título de Link Automático

3. Renderização de Visualização em Tempo Real para @-shortlinks (ex. tweets)

4. Conclusão de Guia/HTML Elétrica

5. Multilíngue com funcionalidade de tradução de IA OOTB — incluindo chinês, hebraico e árabe

6. $\text{Markdown }\rightarrow\LaTeX$ conversor de artigo modelo

Builds Incrementais do Orion

O(N) vs. O(1)

Se você quiser que os autores e editores da sua wiki fiquem felizes com o seu sistema de compilação, ele tem que suportar builds incrementais como um recurso de primeira ordem, e não um truque de marketing abordado como uma reflexão tardia.

O que significa que você quer Orion!

Hugo’s Primitive Dependency Cache (ou seja, Gilding the Lilly)

Níveis comicamente absurdos de sofrimento sem sentido em diagramas arquitetônicos muito detalhados que habilmente evitam declarar os elepantes na sala…

https://deepwiki.com/gohugoio/hugo/3.6-dependency-tracking-and-caching

Aqui está o que essa página não diz sobre o gerenciamento de dependência Hugo:

• inflexível, gerado internamente DAG com base nos layouts de árvore de nó/folha/pacote

• nunca gravado em disco

Hugo não é rastreado readFile suporte a criação incremental de interrupção de chamadas

Vamos examinar o elefante na sala neste artigo:

https://mbuege.com/2025/09/04/hugo-include-shortcode/

A Hugo não rastreia dependências de conteúdo que surgem de códigos curtos e faz suposições rígidas de DAG sobre as dependências de conteúdo que rastreia.

Orion é totalmente rastreado ssi chamadas

Orion nativamente rastreia fileB.md.enDependência de fileA.md.en e irá reconstruí-lo sempre que fileA.md.en é alterado; e as dependências são suplementarmente configuráveis por documento, não simplesmente assumidas pela estrutura heirárquica.

O gráfico de Dependência de Orion é quase nunca um DAG. E é um componente essencial da construção, não apenas uma otimização semi-apoiada da maneira que é com Hugo.

Por exemplo, a própria origem de markdown desta página tem um Dependencies: *.md.pt-BR cabeçalho (você pode vê-lo na captura de tela acima Editor dele, ou clicando no origem link onde as informações do título e do autor são exibidas) que é usado pelo Orion para gerar os itens sob o “Índice” cabeçalho no rodapé da página.
Todos os arquivos neste diretório são igualmente configurados para referência cruzada entre si!

DAG é uma simplificação excessiva dos requisitos de dependência de conteúdo em casos de uso do mundo real.

Controle de Versão

ACLs Git e Detalhadas

Impossível em qualquer DVCS como git — o acesso de leitura ao repositório implica o acesso à sua totalidade, incluindo o histórico completo. Para acesso por push: é tudo ou nada, que é um deal-breaker em um contexto wiki em que diferentes usuários do repositório exigem controles granulares de acesso/autorização de gravação de arquivo/diretório.

Subversão

Integração por usuário trivial com git/GitHub por meio do git-svn ponte empacotada como uma extensão de complemento por cada git distribuição.

Rodapés

1. Para uma comparação de maçãs para maçãs, eu portei um subconjunto do https://www.openoffice.org JBake árvore de origem @apache/openoffice-org para Hugo e comparou-o com um simples hyde baseado no tema que acabou de abater o body innerHTML fora do .html origens (renomeado como .md arquivos com html incorporado) a’la

{{ define "main" -}}
<div class="post">
  <h1>{{ .Title }}</h1>
  <time datetime={{ .Date.Format "2006-01-02T15:04:05Z0700" }} class="post-date">{{ .Date.Format "Mon, Jan 2, 2006" }}</time>
  {{ $matches := findRESubmatch `(?s)<body[^>]*>(.*?)</body>` .Content }}
  {{ range $matches }}{{ index . 1 | safeHTML }}{{ end }}
</div>
{{ if .Site.Config.Services.Disqus.Shortname -}}
<h2>Comments</h2>
{{ template "_internal/disqus.html" . }}
{{- end }}
{{- end }}

E aqui está o hugo.toml arquivo:

baseURL = 'https://openoffice.org/'
languageCode = 'en-us'
title = 'My New Hugo Site'
theme = "hyde"
[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true

Normalmente, levou de 8 a 12 segundos (às vezes até 30s) para processar 10K tais arquivos. Quando comparado ao build @SunStarSys/orion ./test.sh ooo qual constrói consistentemente sobre 20K tais arquivos em aproximadamente 2-3x o tempo, parece que existe paridade de desempenho entre eles em sites menos complexos, mas muito grandes como https://www.OpenOffice.org.

No entanto, Orion é capaz de muito mais se você precisar de verdadeira flexibilidade e corrigir o suporte incremental de construção, porque nós pensamos que você sabe o que funciona melhor para o seu site, ao contrário do resto da comunidade SSG exagerada em torno de Hugo.

2. Suporte total para cercado asy blocos de markdown com origens codificadas em @vectorgraphics/asymptote .