Orion gegen Hugo

[ÜBERPRÜFT] Zuletzt aktualisiert von Joe Schaefer am So., 28 Juni 2026    Quelle

 

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

— SunStar Systems (@sunstarsys) June 27, 2026

Vorwort

Ich verstehe, dass Tech-Vergleiche in vielen Kreisen ein religiöses Tabu sind. Der wichtigste Punkt, den ich zu vermitteln versuche, ist, dass Orion wird als Enterprise Jamstack Wiki abgerechnet, es hat viele brauchbare Anwendungsfälle außerhalb dieser spezifischen Problemdomäne.

Der Kern dieses Artikels besteht jedoch darin, die Apache-Lizenzierte SSG von Orion als eine bessere SSG als Hugo für Sie und Ihre Software-Engineering-Teams darzustellen. Es hat mehr Leistung, mehr Leistung, mehr Kernfunktionen und viel einfacher anzupassen. Plus ist es gut dokumentiert und hat unbegrenztes Potenzial für echte Power-User da draußen, genau wie Sie!

@SunStarSys/orion

• NKOTB

• Einschätzung mit allmählicher Lernkurve

@GoHugoIo/hugo

• Beliebt

• Robuste Themen und Erweiterungen von Drittanbietern

• Einschätzung mit Steep Learning Curve

Allgemeine Funktionssets

• Apache lizenziert

• Hohe Leistung (max. Dokumentverarbeitungsgeschwindigkeit bei ~1K Dokumenten pro Sekunde)[1]

• Gecachtes Abhängigkeitsmanagement

• Ausgereiftes Sicherheitsmodell

Orion als Hugo++

1. (Konfigurierbar) Volle Leistung von Django-Vorlagen in Markdown-Quellen

2. Robuster Steuerungsfluss, For-Loop-Konstrukte und Django-Filter

3. Vollständiger Zugriff auf angehängte YAML/CSV-Dokumente als Datenstrukturen

4. WebGL-fähige Vektorgrafiken[2]

5. Vektorgriffe auf Tabellendaten aggregieren PDL

6. ssi überspringt Dateikopfzeilen

7. Inhaltsverhandlung / MultiViews

8. Einfach zu bedienen

9. Flexible, echte inkrementelle Builds

10. ACL pro Datei/Verzeichnis (auch als fein granulierte ACL bezeichnet), einschließlich Kontrollen des Software-Stacks und der Konfiguration des Builds selbst

11. Robust $\KaTeX$ Hilfe

12. Integrierte PCRE-Suche

Anwendungsfälle für Orion CMS Editor

1. Dokument-Upload-Linting basierend auf MIME-Typ (Markdown, Perl, YAML, CSV, $\LaTeX$)

2. Automatische Linkvalidierung/Titelisierung

3. Echtzeit-Vorschaudarstellung für @-shortlinks (z.B. Tweets)

4. E-HTML/Tab-Abschluss

5. Mehrsprachige KI-Übersetzungsfunktionalität OOTB — einschließlich Chinesisch, Hebräisch und Arabisch

6. $\text{Markdown }\rightarrow\LaTeX$ Vergoldeter Artikelkonverter

Inkrementelle Orion Builds

O(N) vs. O(1)

Wenn Sie möchten, dass die Autoren und Redakteure Ihres Wikis mit Ihrem Build-System zufrieden sind, muss es inkrementelle Builds als Erstbestellfunktion unterstützen, und kein Marketing-Gimmick als Nachdenken.

Das heißt, Sie wollen Orion!

Hugo’s Primitive Dependency Cache (z.B. Gilding the Lilly)

Komisch absurde Ebenen bedeutungslosen Leidens in sehr detaillierten Architekturdiagrammen, die es geschickt vermeiden, die Elefanten im Raum anzugeben…

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

Hier ist, was diese Seite nicht über Hugo Dependency Management sagt:

• unflexibel, intern erzeugt TAG basierend auf Knoten-/Blatt-/Bundle-Baumlayouts

• nie auf Datenträger geschrieben

Hugo’s untracked readFile Aufrufe brechen inkrementelle Build-Unterstützung

Lassen Sie uns den Elefanten im Raum in diesem Artikel untersuchen:

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

*Hugo verfolgt keine inhaltsabhängigkeiten, die aus shortcodes entstehen, und macht starre DAG-annahmen über die inhaltsabhängigkeiten, die es verfolgt.

Orion ist vollständig verfolgt ssi Anrufe

Orion nativ Spuren fileB.md.en‘s Abhängigkeit von fileA.md.en und wird es immer wieder aufbauen fileA.md.en wird geändert; und Abhängigkeiten sind pro Dokument zusätzlich konfigurierbar, nicht nur von der hierarchischen Struktur angenommen.

Orions Dependency Graph ist fast nie eine DAG. Und es ist eine wesentliche Komponente des Builds, nicht nur eine halb unterstützte Optimierung, wie es bei Hugo ist.

Zum Beispiel hat die Markdown-Quelle dieser Webseite selbst eine Dependencies: *.md.de Header (Sie können es im obigen Editor-Screenshot sehen, oder indem Sie auf die Quelle Link, wo der Titel und die Autoreninformationen angezeigt werden), der von Orion verwendet wird, um die Elemente unter dem “Index” Header in der Fußzeile der Seite.
Alle Dateien in diesem Verzeichnis sind ähnlich konfiguriert, um sich gegenseitig zu referenzieren!

Die DAG ist eine grobe Übersimplifizierung der Anforderungen an die Inhaltsabhängigkeit in realen Anwendungsfällen.

Versionskontrolle

Git und fein granulierte ACLs

Unmöglich bei DVCS wie git — Der Lesezugriff auf das Repository impliziert den Zugriff auf seine Gesamtheit, einschließlich der vollständigen Historie. Ditto für Push-Zugriff: Es ist alles oder nichts, was ein Deal-Breaker in einem Wiki-Kontext ist, in dem verschiedene Repository-Benutzer eine granulare Datei / Verzeichnis schreiben Autorisierung / Zugriffskontrolle erfordern.

Subversion

Triviale pro-Benutzer-Integration mit git/GitHub über die git-svn Bridge als Add-on-Erweiterung von jedem git Verteilung.

Fußnoten

[1]. Für einen Vergleich von Äpfeln zu Äpfeln habe ich eine Teilmenge der https://www.openoffice.org JBake Quellbaum @apache/openoffice-org zu Hugo und Benchmarking mit einem einfachen hyde Basiertes Thema, das gerade die body innerHTML von der .html Quellen (umbenannt als .md Dateien mit eingebettetem 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 }}

Und hier ist der hugo.toml Datei:

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

Normalerweise dauerte es 8-12 Sekunden (manchmal bis zu 30s), um 10K-Dateien zu verarbeiten. Im Vergleich zu @SunStarSys/orion build ./test.sh ooo die erstellt konsistent über 20K solche Dateien in etwa 2-3x der ZeitEs scheint, dass es Performanceparität zwischen ihnen auf den am wenigsten komplexen, aber sehr großen Websites wie https://www.OpenOffice.org.

Jedoch Orion ist in der Lage, so viel mehr, wenn Sie echte Flexibilität und korrekte inkrementelle Build-Unterstützung benötigen, denn wir glauben, dass Sie wissen, was am besten für Ihre Website funktioniert, im Gegensatz zum Rest der überhypten SSG-Community um Hugo.

[2]. Vollständige Unterstützung für eingezäunt asy Markdown-Blöcke mit Quellen, die in @vectorgraphics/asymptote codiert sind.