Orion vs. Hugo

[VERIFIERAD] Senast uppdaterad av Joe Schaefer på Sun, 28 Jun 2026    källa

 

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

— SunStar Systems (@sunstarsys) June 27, 2026

Förord

Jag förstår att tekniska jämförelser är ett religiöst tabu i många kretsar. Det viktigaste jag försöker förmedla är att medan Orion Den faktureras som en Enterprise Jamstack Wiki, den har många livskraftiga användningsfall utanför den specifika problemdomänen.

Men kärnan i den här artikeln är att representera Orions Apache-Licensed SSG som *en bättre SSG än Hugo för dig och dina programvarutekniker *. Den har mer kraft, mer prestanda, fler kärnfunktioner och mycket enklare att anpassa. Plus att det är väldokumenterad och har obegränsad potential för riktiga strömanvändare där ute, precis som du!

@SunStarSys/orion

• NKOTB

• Yttrande med gradvis inlärningskurva

@GoHugoIo/hugo

• Populär

• Robusta teman och tillägg från tredje part

• Yttrande med brant inlärningskurva

Gemensamma funktionsuppsättningar

• Apache licensierad

• Hög prestanda (max dokumentbearbetningshastighet vid ~1K dokument per sekund)¹

• Cachelagrad beroendehantering

• Sofistikerad säkerhetsmodell

Orion som Hugo++

1. (Konfigurerbar) Full kraft av Django mallar inom Markdown källor

2. Robust kontrollflöde, For-Loop konstruktioner och Django filter

3. Full åtkomst till bifogade YAML/CSV-dokument som datastrukturer

4. WebGL-aktiverad vektorgrafik²

5. Aggregera vektoråtgärder på tabelldata via PDL

6. ssi hoppar över filhuvuden

7. Innehållsförhandling / MultiViews

8. Lätt att använda

9. Flexibla, sanna inkrementella byggen

10. Åtkomstkontrollista per fil/katalog (även kallad finkornig) inklusive kontroller av själva byggets programvarustack och konfiguration

11. Robust $\KaTeX$ Stöd

12. Integrerad PCRE-sökning

Användningsfall för Orion CMS-redigerare

1. Luddning för dokumentuppladdning baserad på MIME-typ (nedsättning, perl, YAML, CSV, $\LaTeX$)

2. Automatisk länkvalidering/rubrikering

3. Förhandsgranskningsåtergivning i realtid för @-kortlänkar (t.ex. tweets)

4. Slutförande av elektrisk HTML/flik

5. Flerspråkig med AI-översättningsfunktion OOTB — inklusive kinesiska, hebreiska och arabiska

6. $\text{Markdown }\rightarrow\LaTeX$ templad artikelomvandlare

Inkrementella Orion-byggen

O(N) kontra O(1)

Om du vill att din wikis författare och redaktörer ska vara nöjda med ditt byggsystem, måste det stödja inkrementella byggen som en första orderfunktion, och inte en marknadsföringsgimmick som tackas på som en eftertanke.

Det betyder att du vill ha Orion!

Hugos primitiva beroendecache (dvs. Gilding the Lilly)

Komiskt absurda nivåer av meningslös puffery i mycket detaljerade arkitektoniska diagram som skickligt undviker att ange elepanterna i rummet…

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

Här är vad den sidan inte säger om Hugo beroendehantering:

• oflexibel, internt genererad DAG baserat på nod-/löv-/paketträdlayouter

• aldrig skriven till disk

Hugos spårlösa readFile anropar stöd för inkrementell bygge för brytning

Låt oss undersöka elefanten i rummet i den här artikeln:

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

Hugo spårar inte innehållsberoenden som uppstår från kortkoder och gör rigida DAG-antaganden om innehållsberoenden som den spårar.

Orions spårade ssi samtal

Orion spårar internt fileB.md.en‘s beroende av fileA.md.en och kommer att återuppbygga den när som helst fileA.md.en ändras, och beroenden är kompletterande konfigurerbara per dokument, inte bara antas av arvarkisk struktur.

Orions beroendediagram är nästan aldrig en DAG. Och det är en viktig del av byggandet, inte bara en halvbackad optimering som det är med Hugo.

Till exempel har den här webbplatsens nedsättningskälla själv en Dependencies: *.md.sv sidhuvud (du kan se det i ovanstående Editor skärmdump av det, eller genom att klicka på källa länk där titel- och författarinformation visas) som används av Orion för att generera objekten under “Index” sidhuvud i sidans sidfot.
Alla filer i den här katalogen är på samma sätt konfigurerade att korsreferera varandra!

DAG är en bruttoförenkling av kraven på innehållsberoende i verkliga användningsfall.

Versionskontroll

Git- och finjusterade åtkomstkontrollistor

Omöjligt i alla DVCS som git — läsåtkomst till databasen innebär åtkomst till hela databasen, inklusive fullständig historik. Ditto för push-åtkomst: det är allt-eller-ingenting, vilket är en deal-breaker i en wiki-kontext där olika databasanvändare kräver detaljerad fil / katalog skrivbehörighet / åtkomstkontroller.

Subversion

Trivial per-user-integrering med git/GitHub via git-svn brygga paketerad som en tilläggstillägg av varje git distribution.

Fotnoter

1. För en jämförelse mellan äpplen och äpplen porterade jag en delmängd av https://www.openoffice.org JBake källträd @apache/openoffice-org till Hugo och riktmärkte det mot en enkel hyde baserat tema som bara kullade body innerHTML utanför .html källor (namnändras som .md filer med inbäddade html) 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 }}

Och här är den hugo.toml fil:

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

Det tog vanligtvis 8-12 sekunder (ibland upp till 30s) att bearbeta 10K sådana filer. Jämfört med @SunStarSys/orion build ./test.sh ooo vilket konsekvent bygger över 20K sådana filer i ungefär 2-3x tiden, det verkar som om det finns prestanda paritet mellan dem på de minst komplexa men mycket stora webbplatser som https://www.OpenOffice.org.

Men, Orion är kapabel till så mycket mer om du behöver sann flexibilitet och korrekt inkrementell byggstöd, eftersom vi tror att du vet vad som fungerar bäst för din webbplats, till skillnad från resten av den överhypade SSG-gemenskapen runt Hugo.

2. Fullt stöd för inhägnad asy Markdown-block med källor kodade i @vectorgraphics/asymptote .