אוריון נגד הוגו

[אומתו] עודכן לאחרונה מאת Joe Schaefer ב-יום א׳, 28 יוני 2026    מקור

 

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

— SunStar Systems (@sunstarsys) June 27, 2026

הקדמה

אני מבין שההשוואות הטכניות הן טאבו דתי בחוגים רבים. הנקודה העיקרית שאני מנסה להעביר היא כי אוריון הוא מחויב כמו Enterprise Jamstack Wiki, יש לו הרבה מקרי שימוש קיימא מחוץ לתחום הבעיה הספציפי הזה.

עם זאת, תמצית מאמר זה היא לייצג את ה- SSG של אוריון כמו SSG טוב יותר מאשר הוגו בשבילך ואת צוותי הנדסת התוכנה שלך*. יש לו יותר עוצמה, יותר ביצועים, יותר תכונות ליבה, והרבה יותר קל להתאים אישית. בנוסף, מתועד היטב ויש לו פוטנציאל בלתי מוגבל למשתמשי כוח אמיתיים שם בחוץ, בדיוק כמוך!

@SunStarSys/אזור

• נקוטב

• בעל דעה עם עקומת למידה הדרגתית

@GoHugoIo/הוגו

• פופולרי

• ערכות נושא והרחבות חזקות של צד שלישי

• חוות דעת עם עקומת למידה תלולה

סלי מאפיינים משותפים

אפאצ’י מורשה

• ביצועים גבוהים (מהירות עיבוד מרבית של מסמכים בכ- ~1K מסמכים לשנייה)¹

• ניהול תלות במטמון

• מודל אבטחה מתוחכם

אוריון - הוגו++

1. (ניתן להגדרה) עוצמה מלאה של תבניות Django בתוך מקורות Markdown

2. זרימת בקרה חזקה, מבני For-Loop ומסנני Django

3. גישה מלאה למסמכים מצורפים של YAML/CSV כמבני נתונים

4. WebGL - גרפיקה וקטורית מאופשרת²

5. סכימת פעולות וקטוריות בנתוני טבלה באמצעות PDL

6. ssi מדלג על כותרות קבצים

7. מכרז תוכן / MultiViews

8. קל לשימוש

9. בניות גידול גמישות ואמיתיות

10. ACL לכל קובץ/ספרייה, כולל פקדים על מחסנית התוכנה והגדרת התצורה עצמה של הבנייה

11. חזק $\KaTeX$ תמיכה

12. חיפוש משולב ב־PCRE

מקרי שימוש של עורך CMS של אוריון

1. סימון טעינת מסמך מבוסס על סוג MIME (סימון מטה, פרל, YAML, CSV, $\LaTeX$)

2. אימות/כותרת של קישור אוטומטי

3. הצגה לתצוגה מקדימה בזמן אמת של @-קישורים קצרים (לדוגמה) ציוצים

4. השלמת HTML/לשונית חשמלית

5. OOTB: פונקציונליות תרגום רב-לשונית עם בינה מלאכותית — כולל סינית, עברית וערבית

6. $\text{Markdown }\rightarrow\LaTeX$ ממיר מאמר זמני

בניות תוספתיות של אוריון

O(N) לעומת O(1)

אם אתה רוצה שהסופרים והעורכים של הוויקי שלך יהיו מרוצים ממערכת הבנייה שלך, הוא צריך לתמוך בבניות תוספתיות כתכונת הזמנה ראשונה, ו לא גימיק שיווקי המתמודד כמחשבה מאוחרת.

מה שאומר שאתה רוצה אוריון!

מטמון התלות הפרימיטיבי של הוגו (כלומר, גילדינג לילי)

רמות אבסורדיות של נפיחות חסרת משמעות בדיאגרמות אדריכליות מפורטות מאוד, אשר נמנעות בכובד ראש מלציין את הפילים בחדר…

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

הנה מה שהדף הזה לא אומר על ניהול התלות של הוגו:

• לא גמיש, שנוצר באופן פנימי דאג מבוסס על מתווי עץ של צומת/עלה/חבילה

מעולם לא נכתב בדיסק

של הוגו readFile קריאות להפסקת תמיכה בבנייה תוספתית

הבה נבחן את הפיל שבחדר במאמר זה:

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

הוגו אינו עוקב אחר יחסי תלות של תוכן הנובעים מקודים קצרים, ומבצעת הנחות קשות על DAG לגבי יחסי התלות בין התוכן שעוקבים אחריהם.

המעקב המלא של אוריון ssi שיחות

אוריון עקבות fileB.md.enהתלות ב- fileA.md.en הוא יבנה אותה מחדש בכל פעם fileA.md.en הוא משתנה; ויחסי התלות ניתנים להגדרה נוספת לכל מסמך, והם לא נלקחים בחשבון רק באמצעות מבנה היררכי.

גרף התלות של אוריון הוא כמעט אף פעם לא DAG. וזה מרכיב חיוני של הבנייה, לא רק אופטימיזציה חצי מגובה כפי שהוא עם הוגו.

לדוגמה, למקור markdown של דף אינטרנט זה עצמו יש Dependencies: *.md.he כותרת עליונה (ניתן לראות אותה בצילום המסך של העורך לעיל, או על-ידי לחיצה על מקור קישור שבו מוצגים פרטי הכותרת והמחבר) המשמשים את אוריון ליצירת הפריטים תחת “אינדקס” כותרת עליונה בכותרת התחתונה של הדף.
כל הקבצים בספרייה זו מוגדרים באופן דומה להפניה מקושרת זה לזה!

DAG הוא פשט יתר ברוטו של דרישות תלות התוכן בתרחישי שימוש בעולם האמיתי.

בקרת גרסאות

רשימות בקרת גישה של Git ו-Fine-Grained

בלתי אפשרי בכל DVCS כמו git — גישת הקריאה למאגר מרמזת על גישה בשלמותה, כולל היסטוריה מלאה. Ditto עבור גישת דחיפה: זה הכל או כלום, שהוא שובר עסקה בהקשר wiki שבו משתמשים שונים במאגר דורשים אישור/בקרות גישה מפורטות לכתיבת קובץ/ספרייה.

תת-גרסה

שילוב טריוויאלי למשתמש עם git/GitHub דרך git-svn גשר ארוז כתוספת הרחבה על־ידי כל git הפצה.

הערות שוליים

1. לשם השוואה בין תפוחים לתפוחים הנחתי תת-קבוצה של https://www.openoffice.org JBake עץ מקור @apache/openoffice-org ל-Hugo ובחן אותו כנגד עץ פשוט hyde נושא שפשוט עורר את body innerHTML מתוך .html מקור (שמו שונה) .md קבצים עם 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 }}

והנה הוא hugo.toml קובץ:

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

בדרך כלל נדרשו 8-12 שניות (לפעמים עד 30s) כדי לעבד 10K קבצים כאלה. בהשוואה ל-@SunStarSys/orion build ./test.sh ooo אשר בונה באופן עקבי מעל 20K קבצים כאלה בערך 2-3x הזמןנראה שיש זוגיות ביצועים ביניהם באתרים הפחות מורכבים אך גדולים כמו https://www.OpenOffice.org.

עם זאת, אוריון הוא מסוגל להרבה יותר אם אתה זקוק לגמישות אמיתית ולתמיכה בבנייה תוספתית נכונה, כי אנחנו חושבים שאתה יודע מה עובד הכי טוב עבור האתר שלך, בניגוד לשאר קהילת SSG שהשתרעה סביב הוגו.

2. תמיכה מלאה בגדר asy בלוקי markdown עם מקורות מקודדים ב-@vectorgraphics/asymptote .