IMO one of the big advantages of Jekyll is that you can extend and modify it to no end, which is a lot harder in Hugo. The choice of language plays a big part here: Ruby just makes this kind of stuff a lot easier than Go.

On my website I do stuff like:

- Run Vim to add syntax highlighting (with :ToHTML).

- Add a tag to include a code example from an external file (much easier to test/run when writing!)

- A tag to list "related posts" based on tag.

- Overwrite the standard date formatting function so I use my own date format, and add a custom number format function which uses a thin space to separate thousands.

- Generate pages for my Go "vanity paths" based on just an Array in a Ruby plugin.

- A tag to include images as base64 inside the page itself.

- Run some regexps on the generated HTML to add/change some things.

- Aside from the .html page, it also generates .txt files for people who prefer this and/or usage on Gopher/Gemini (actually, I removed this as it never worked quite how I wanted, but with a little bit of extra effort it would have, I just couldn't be bothered).

Maybe it's crazy to do some of these things like running Vim, but I like the Vim colour scheme and semantics and it's a lot easier to use this than configuring some library. I wrote much of this years ago and has been working without problems ever since, and it didn't even cost me that much effort.

Either way, my point is: this is a major advantage of Jekyll. Hugo probably has some of this by default, but last time I checked you couldn't even add a custom template function. Once you reach the limits of what you can do with Hugo: you're going to have a hard time. If you hit the limits with Jekyll: no problem, lemme just whip up some Ruby code.

I never hit "random quirks" though, in spite of all my hacky stuff.

There are some cases where re-writes in Go or Rust are just so good that the "originals" become almost entirely obsolete. Hugo is one of those tools, ESbuild seems to be another, or ripgrep for Rust for example.

> There are some cases where re-writes in Go or Rust are just so good that the "originals" become almost entirely obsolete.

Why's that?

I use Jekyll here and even with over 500+ articles (posts + drafts) it takes around 2 seconds to get live reload feedback in Jekyll while writing. Jekyll also handles the entire asset pipeline complete with md5 tagging of assets without using Webpack or any build tools. It also lets you write plugins with a few lines of Ruby to add new template filters and other things.

For example I wrote a custom Jekyll plugin that lets me write bullet lists like this after a specific type of header:

    - 0:45 -- Something
    - 1:45 -- Another thing
    - 1:03:31 -- And another thing

And it automatically converts the timestamp numbers into clickable links that jump to that point in an audio player.

AFAIK Hugo has no way to do anything like that, at least no where near as easy as Jekyll. With Hugo wouldn't I have to compile a custom build of Hugo for such a thing? But with Jekyll it was adding 1 file into a directory and writing 20 lines of "business logic code" to add a new filter. Now I just do {{ content | audioseek }} when I want clickable timestamps.

I also wrote another plugin that automatically adds certain rel attributes to external links by adding {{ content | extlinks }}.

Things like the above are why I continue using Jekyll because personally I haven't found another SSG that comes close to how easy it makes it to add custom behavior. I don't mind the 2 second live reload wait and I wouldn't switch away from Jekyll for a speed boost alone. At some point the speed is "good enough". Sure I would love a 100ms reload but I wouldn't give up everything else for that.

Hugo has one-file creation of shortcodes + config params too, which IIRC is the same workflow as doing it in Jekyll: https://gohugo.io/templates/shortcode-templates/

Extending the Markdown rendering appears possible without building Hugo itself, albeit not for lists: https://gohugo.io/getting-started/configuration-markup/#mark...

I'm not sure if either of the things you linked would solve this specific problem but I also only skimmed the pages you linked.

For example the Jekyll plugin for the timestamps:

    1. Looks for a specific type of post and then it scans the body of the post
    2. Looks for a specific header on the page and then grabs the list right after that header using an xpath selector (no special classes needed)
    3. Goes through all of the elements in the list
    4. Parses out the timestamp from the line and changes the timestamp into a link with a data attribute containing a specific timestamp format

The code for this is here: https://github.com/nickjj/runninginproduction.com/blob/maste...

There's no custom Markdown or even classes added to the list or post because it lets you naturally write your Markdown list how you would if the feature didn't exist, and the plugin's goal is to add in that new behavior behind the scenes. This lets me keep all of my posts really clean[0].

It would be super interesting to see a Hugo equivalent for the audio_seek custom filter. I don't expect you to spend your Sunday afternoon writing such a thing but it would be cool to see a direct comparison of how you would implement it with Hugo. It might get more folks to move to Hugo too, because the main thing that keeps me using Jekyll is the ability to create adhoc customizations without needing to fork Jekyll.

[0]: https://github.com/nickjj/runninginproduction.com/blob/maste...

That particular example could theoretically be replicated with rendering the content to HTML via .RenderString (https://gohugo.io/functions/renderstring/) + replaceRE (https://gohugo.io/functions/replacere/) + an ugly regex, with a layout override to call that modified filter instead of the normal content.

Not 100% sure if that would work, but on paper business logic LOC would be about the same and using a regex is the more canonical way to handle this sort of processing anyways.

> using a regex is the more canonical way

Yuck.

I also ran into similar issue with Hugo, where I'm out of the happy-path. Those short codes didn't work, complex processing of some unique bits of content was easier in Jekyll (but also other script-lang based tools) than it was in tools like Hugo.

> with a layout override to call that modified filter instead of the normal content

Would it apply to all content in a specific layout or only specific bits of a certain layout?

With the way I have it set up with Jekyll, only a specific post gets the audioseek timestamps added to it, because I wouldn't want it to apply to all lists on the site. I also happen to share a single layout for both podcasts and interviews and interview lists shouldn't get processed with audioseek'd timestamps.

With Jekyll this is super easy to pull off because it's only a custom filter. It can be applied to the specific content I want without having to worry about layouts.

I considered switching to Hugo a while back but ended up sticking with Jekyll for the extensibility, like a few others have said. I'm particularly interested in image thumbnailing and format conversion since so many of my posts are image-heavy. I often found that to be my biggest and most frequent barrier to writing since plain text only goes so far on the modern web.

In Hugo, every solution I've seen uses a custom shortcode or custom Markdown image template-rendering hook along with Hugo's build-in image resizing. Many posts even suggest converting image resources to different formats with an external tool. It does seem like the image handling situation in Hugo is improving since it just gained WebP processing support in addition to JPEG: https://gohugo.io/news/0.83.0-relnotes/

Jekyll plugins offer way more power than a shortcode ('include' in Jekyll-speak) can, like how the author of the OP is using Jekyll-Picture-Tag. I've been working on my own similar plugin to handle converting and embedding my site's images, videos, SVGs, PDFs, text files, fonts and weird retro computer formats, etc. For example I can embed an SVG using standard Markdown syntax like `` and get a <picture> tag with the SVG plus rasterized JPG+WebP+AVIF+whatever at multiple sizes all totally seamlessly: https://github.com/okeeblow/DistorteD

Very happy the existence of Hugo lit a fire under the Jekyll team to work on speed though :)

I also tried Hugo in 2020 for my personal homepage and thought it's incredible hard to use if you do not want to use it as a blog. My homepage consists of multiple different pages with different designs and the hoops I had to jump and documentations/blogs to read to find out how to do it was much more time than I wanted to invest in this topic. I can't recommend it at all.

My main gripe that it has expanded and changed too much over the years, it seems they want it to do everything now and it's about as complex to configure as it is to write your own simple tool...

Sure, some software needs to be cared for and polished, but hugo was one of those where I converted my site to it, then it simply ran. It's a binary running locally, I don't care about security updates (as I only run it on my own user input) and until I stumble over a bug I can keep using this version as long as the OS will run it..

I agree completely about Hugo. It’s so fast (1099ms for 502 pages) that I have a publishing pipeline like:

* Edit a page on my laptop or iPad with iA Writer.

* Commit it to git and push it to a repo I host.

* Every 5 minutes, a cron job runs on the server that does `git pull && hugo && rsync` to update the live site.

Jekyll took half a minute to do the same build that Hugo does in 1 second, and now the process is so fast that this workflow is practical.

I'm using Hugo for my blog, so this is good to hear. My only complaint so far is having to embed front matter in my .md files. Mixing JSON and Markdown feels wrong.

Question: my blog is a git repo of .md files that I run through Hugo and then rsync to my host. Wouldn't it be possible to write a web app that just hits the repo on Github and renders to HTML, and skip Hugo altogether? Are there downsides other than performance?

The main point of a static website is that you don't need a web app to serve it, any web server that can serve files (all of them) will do.

I use my own static site generator to generate the final HTML/CSS (but could be using Hugo or Jekyll or anything else)... when I push the generated files on my gitHub repo, Netlify automatically detects it and starts serving the new files. That's pretty much what you probably actually want.

Takes less than 5 minutes to get it setup.

Note: I have no afilliation with Netlify, just a happy customer.

https://www.netlify.com/blog/2016/10/27/a-step-by-step-guide...

That's good to know, thanks!

Couldn't I hit Github using just statically served, client side JS?

Checkout GitHub pages.. it might be useful for you

Front matter is the same with both Jekyll and Hugo, and it's certainly better than the alternative for per-post config which is an unavoidable constraint.

It's theoretically possible to do automatic-render-on-commit-and-sync with GitHub Actions, although I haven't investigated it. There wouldn't be much of a performance hit either.

Jekyll GitHub intergration works for a quick website.

It's suggest gatsby. You'll need javascript at some point and you don't want to deal with generated javascript or some hacked together javascript.

Anything else that's not js, imo you're making the biggest mistake... Eventually you'll need js...