Orion vs. Hugo

[VERIFIED] Last updated by Joe Schaefer on Tue, 14 Jul 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

Preface

I understand that tech comparisons are a religious taboo in many circles. The main point I’m trying to convey is that while Orion is billed as an Enterprise Jamstack Wiki, it has many viable use-cases outside of that specific problem domain.

However, the gist of this article is to represent Orion’s Apache-Licensed SSG as a better SSG than Hugo for you and your software engineering teams. It has more power, more performance, more core features, and is a lot easier to customize. Plus it is well-documented and has unlimited potential for true power users out there, just like you!

Yes, speed matters! But so does flexibility, balance, and power. Unlike Hugo, Orion is capable of handling all four corners of your site’s needs. Not just one.

With Orion’s IoC build API, you can tune sections of your site’s build to prioritize any aspect it needs, and still enjoy the efficiency of true incremental builds for the bulk of your team’s work.

@SunStarSys/orion

• NKOTB

• Opinionated w/ Gradual Learning Curve

@GoHugoIo/hugo

• Popular

• Robust Third-Party Themes and Extensions

• Opinionated w/ Steep Learning Curve

Common Feature Sets

• Apache Licensed

• High Performance (max document processing speed at ~1K documents per second)¹

• Cached Dependency Management

• Sophisticated Security Model

Orion as Hugo++

1. (Configurable) Full power of Django Templates within Markdown sources

2. Robust Control Flow, For-Loop Constructs, and Django Filters

3. Full Access To YAML/CSV attached documents as data structures

4. WebGL-enabled Vector Graphics²

5. Aggregate Vector Operations on Table Data via PDL

6. ssi skips file headers

7. Content Negotiation / MultiViews

8. Easy to Use

9. Flexible, True Incremental Builds

10. Per-file/directory (aka fine-grained) ACL, including controls on the build’s software stack and configuration itself

11. Robust $\KaTeX$ Support

12. Integrated PCRE Search

Orion CMS Editor Use Cases

1. Document Upload Linting based on MIME-type (Markdown, Perl, YAML, CSV, $\LaTeX$)

2. Automatic Link Validation / Titleization

3. Real Time Preview Rendering for @-shortlinks (eg tweets)

4. Electric HTML/Tab Completion

5. Multilingual w/ AI translation functionality OOTB — including Chinese, Hebrew and Arabic

6. $\text{Markdown }\rightarrow\LaTeX$ templated article converter

Orion Incremental Builds

O(N) vs. O(1)

If you want your wiki’s authors and editors to be happy with your build system, it has to support incremental builds as a first order feature, and not a marketing gimmick tacked on as an afterthought.

Which means you want Orion!

Hugo’s Primitive Dependency Cache (i.e., Gilding the Lilly)

Comically absurd levels of meaningless puffery in very detailed architectural diagrams which deftly avoid stating the elepants in the room…

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

Here’s what that page doesn’t say about Hugo dependency management:

• inflexible, internally generated DAG based on node/leaf/bundle tree layouts

• never written to disk

Hugo’s untracked readFile calls break incremental build support

Let’s examine the elephant in the room in this article:

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

Hugo does not track content dependencies that arise from shortcodes, and makes rigid DAG assumptions about the content dependencies it does track.

Orion’s fully tracked ssi calls

Orion natively tracks fileB.md.en‘s dependency on fileA.md.en and will rebuild it whenever fileA.md.en is altered; and dependencies are supplementally configurable per document, not simply assumed by heirarchical structure.

Orion’s Dependency graph is almost never a DAG. And it is an essential component of the build, not merely a half-baked optimization the way it is with Hugo.

For example, this webpage’s markdown source itself has a Dependencies: *.md.en header (you can see it in the above Editor screenshot of it, or by clicking on the source link where the title and author information is displayed) which is used by Orion to generate the items under the “Index” header in the footer of the page.
All of the files in this directory are similarly configured to cross-reference each other!

DAG is a gross oversimplification of the content dependency requirements in real-world use cases.

Version Control

Git and Fine-Grained ACLs

Impossible in any DVCS like git — read access to the repository implies access to its entirety, including full history. Ditto for push access: it is all-or-nothing, which is a deal-breaker in a wiki context where different repository users require granular file/directory write authorization/access controls.

Subversion

Trivial per-user integration with git/GitHub via the git-svn bridge bundled as an addon extension by every git distribution.

Footnotes

1. For an apples-to-apples comparison I ported a subset of the https://www.openoffice.org JBake source tree @apache/openoffice-org to Hugo and benchmarked it against a simple hyde based theme that just culled the body innerHTML out of the .html sources (renamed as .md files with embedded 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 }}

And here is the hugo.toml file:

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

It typically took 10-25 seconds (sometimes up to 40s) to process 11K such files and a sizable corpus of static assets, even on rebuild with fully populated filesystem cache.

/src/hugo-test/myblog(1)% hugo                                                                                                  74GB💾 1:04PM master✔✗
Start building sites …
hugo v0.154.5+extended linux/amd64 BuildDate=2026-01-13T19:59:22Z VendorInfo=ubuntu:0.154.5-1


                  │  EN
──────────────────┼───────
 Pages            │ 11020
 Paginator pages  │     0
 Non-page files   │     2
 Static files     │ 15979
 Processed images │     0
 Aliases          │     0
 Cleaned          │     0

Total in 18730 ms
19s ~/src/hugo-test/myblog% hugo                                                                                                     72GB💾 1:05PM master✔✗
Start building sites …
hugo v0.154.5+extended linux/amd64 BuildDate=2026-01-13T19:59:22Z VendorInfo=ubuntu:0.154.5-1


                  │  EN
──────────────────┼───────
 Pages            │ 11020
 Paginator pages  │     0
 Non-page files   │     2
 Static files     │ 15979
 Processed images │     0
 Aliases          │     0
 Cleaned          │     0

Total in 24974 ms

When compared to @SunStarSys/orion build ./test.sh ooo which consistently builds over 20K such files, with the same corpus of static assets (that Orion gzip compresses automatically, unlike Hugo), in roughly the same time, it seems there is performance parity between them on the least complex yet very large websites like https://www.OpenOffice.org.

However, Orion is capable of so much more if you need true flexibility and correct incremental build support, because we think you know what works best for your site, unlike the rest of the overhyped SSG community around Hugo.

A site like https://iconoclasts.blog/ takes Orion 10-100x longer to build each blogging page because the pages are very complex! In these cases, incremental build support is absolutely critical.

2. Full support for fenced asy markdown blocks with sources coded in @vectorgraphics/asymptote .