Orion contre Hugo

[VÉRIFIÉ] Dernière mise à jour par Joe Schaefer sur dim., 28 juin 2026    source

 

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

— SunStar Systems (@sunstarsys) June 27, 2026

Préface

Je comprends que les comparaisons technologiques sont un tabou religieux dans de nombreux cercles. Le point principal que j’essaie de transmettre est que pendant Orion est facturé en tant qu’Enterprise Jamstack Wiki, il a de nombreux cas d’utilisation viables en dehors de ce domaine de problème spécifique.

Cependant, l’essentiel de cet article est de représenter la SSG Apache-Licensed d’Orion comme une meilleure SSG que Hugo pour vous et vos équipes d’ingénierie logicielle. Il a plus de puissance, plus de performances, plus de fonctionnalités de base et beaucoup plus facile à personnaliser. Plus il est bien documenté et a un potentiel illimité pour les vrais utilisateurs de pouvoir là-bas, tout comme vous !

@SunStarSys/orion

• NKOTB

• Opinion avec courbe d’apprentissage graduel

@GoHugoIo/hugo

• Populaire

• Thèmes et extensions tiers robustes

• Opinion avec courbe d’apprentissage raide

Jeux de fonctionnalités communs

• Apache sous licence

• Haute performance (vitesse maximale de traitement des documents à ~1K documents par seconde)¹

• Gestion des dépendances mises en cache

• Modèle de sécurité sophistiqué

Orion comme Hugo++

1. (Configurable) Pleine puissance des modèles Django dans les sources Markdown

2. Flux de contrôle robuste, constructions for-Loop et filtres Django

3. Accès complet aux documents joints YAML/CSV en tant que structures de données

4. Graphiques vectoriels compatibles avec WebGL²

5. Agréger les opérations vectorielles sur les données de table via PDL

6. ssi ignore les en-têtes de fichier

7. Négociation de contenu / MultiViews

8. Facile à utiliser

9. Builds incrémentiels flexibles et vrais

10. ACL par fichier/répertoire (également appelée ACL à niveau fin), y compris les contrôles sur la pile logicielle et la configuration du build elle-même

11. Robuste $\KaTeX$ Assistance

12. Recherche PCRE intégrée

Cas d’utilisation de l’éditeur Orion CMS

1. Chargement de documents Linting basé sur le type MIME (Markdown, Perl, YAML, CSV, $\LaTeX$)

2. Validation/titre de lien automatique

3. Aperçu du rendu en temps réel pour @-liens courts (p. ex. tweets)

4. Fin HTML/tabulation électrique

5. Fonctionnalité multilingue avec traduction IA OOTB — y compris chinois, hébreu et arabe

6. $\text{Markdown }\rightarrow\LaTeX$ Convertisseur d’article

Builds incrémentiels Orion

O(N) vs. O(1)

Si vous voulez que les auteurs et les éditeurs de votre wiki soient satisfaits de votre système de construction, il doit prendre en charge les constructions incrémentielles en tant que fonction de première commande, et pas un gadget marketing abordé après coup.

Ce qui signifie que vous voulez Orion !

Le cache de dépendance primitif de Hugo (c.-à-d. Gilding the Lilly)

Des niveaux absurdes de bouffées insignifiantes dans des schémas architecturaux très détaillés qui évitent habilement d’indiquer les élépants dans la pièce…

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

Voici ce que cette page ne dit pas sur la gestion des dépendances Hugo :

• inflexible, généré en interne DAG basé sur les présentations de noeud/feuille/bundle

• jamais écrit sur le disque

Non suivi par Hugo readFile appels interrompent la prise en charge de la construction incrémentielle

Examinons l’éléphant dans la pièce dans cet article :

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

*Hugo ne suit pas les dépendances de contenu qui découlent des shortcodes, et fait des hypothèses DAG rigides sur les dépendances de contenu qu’il suit.

Orion est entièrement suivi ssi appels

Orion traque nativement fileB.md.enLa dépendance de fileA.md.en et le rebâtira chaque fois fileA.md.en est modifié ; et les dépendances sont configurables de manière supplémentaire par document, et non simplement supposées par une structure hiérarchique.

Le graphique de dépendance d’Orion est presque jamais un DAG. Et c’est un élément essentiel de la construction, pas seulement une optimisation à moitié soutenue comme c’est le cas avec Hugo.

Par exemple, la source de démarque de cette page Web a elle-même une Dependencies: *.md.fr en-tête (vous pouvez le voir dans la capture d’écran ci-dessus de l’éditeur, ou en cliquant sur le source lien où les informations sur le titre et l’auteur sont affichées) qui est utilisé par Orion pour générer les éléments sous “Index” en-tête dans le pied de page de la page.
Tous les fichiers de ce répertoire sont configurés de la même manière pour faire référence les uns aux autres !

Le DAG est une simplification excessive des exigences de dépendance de contenu dans les cas d’utilisation réels.

Contrôle de version

ACL Git et fine

Impossible dans n’importe quel DVCS comme git — l’accès en lecture au référentiel implique l’accès à l’intégralité du référentiel, y compris l’historique complet. Ditto pour l’accès push : c’est tout ou rien, qui est un deal-breaker dans un contexte wiki où les différents utilisateurs du référentiel nécessitent des contrôles granulaires d’autorisation d’écriture de fichier / répertoire / d’accès.

Subversion

Intégration par utilisateur triviale avec git/GitHub via le git-svn pont groupé comme extension d’extension par chaque git distribution.

Notes de bas de page

1. Pour une comparaison de pommes à pommes, j’ai porté un sous-ensemble de https://www.openoffice.org JBake source tree @apache/openoffice-org à Hugo et l’a comparé à un simple hyde thème qui vient d’aboutir body innerHTML sur .html sources (renommées comme .md fichiers avec html intégré) 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 }}

Et voici le hugo.toml fichier :

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

En général, le traitement de ces fichiers par 10K a pris entre 8 et 12 secondes (parfois jusqu’à 30s). Comparé au build @SunStarSys/orion ./test.sh ooo qui construit systématiquement sur 20K ces fichiers dans environ 2-3x le temps, il semble qu’il y ait parité de performances entre eux sur les sites Web les moins complexes mais très volumineux comme https://www.OpenOffice.org.

Cependant, Orion est capable de bien plus si vous avez besoin d’une véritable flexibilité et d’un support de construction incrémentiel correct, car nous pensons que vous savez ce qui fonctionne le mieux pour votre site, contrairement au reste de la communauté SSG surestimée autour d’Hugo.

2. Support complet pour clôturé asy blocs de démarque avec des sources codées dans @vectorgraphics/asymptote .