The --self-extracting flag in deno compile --self-extracting looks awesome.
I could compile my 11ty stack into a single executable that I could send anywhere, but it would still be able to read external markdowns so semi-technical coworkers can make content changes without the maintenance overhead of a CMS and without the coworkers needing to learn modern web dev.
It would also be super awesome for all the internal tools I've built that need to run offline.
I haven't used Hugo.
I went with 11ty a few years ago because I wanted to stay as close to the actual web standards as possible (so, HTML/CSS/JS).
The main reason why is that every additional abstraction layer and every invocation of "magic", is just extra hidden complexity which makes things harder to debug, extend, and maintain.
Having a SSG in go/python/rust would have been an extra layer.
The "maintain" point above is something most others don't think about until it comes back to bite them. Nothing is more frustrating than reopening a project that worked fine a few years ago, and even though you haven't changed anything, nothing works, and when trying to update it you end up with Frankenstein's monster.
11ty went out of it's way to remain as simple as possible. Here's your input directory, and here's your output directory. That makes the maintenance and backwards compatibility really easy.
Then you can add the minimum required complexity/abstraction layers only when you need them.
In my case, I use:
I'll say the one thing I don't like about 11ty is that it's written in js, not ts. The author is all about simplicity and reducing layers of complexity. But now typescript has a typescript-lite version with the erasableSyntaxOnly flag, which basically allows it to run on node (deno and bun already ran typescript), so the next version (or one after), may be migrated to typescript.