Gojekyll: A fast, partially compatible Go clone of Jekyll (opens in new tab)

I completely agree. The go templating language is a nightmare. I probably learned most when dealing with Helm, but I've always been holding out hoping that something better would replace it.

Does anyone know why the templating situation is the way it is in go? In many other languages you have multiple competing templating languages, but in go this is basically what you get. Are there language specific features that make it hard?

EDIT: interesting to final see active liquid templating engines for go. now if only legacy would allow for the use of these things.

This project uses another templating language, apparently based on Shopify's liquid like Jekyll.

(1) https://github.com/osteele/liquid

Hugo's documentation isn't good, no doubt. But compared to Jekyll's docs, there's at least a lot of (reference) content. Jekyll's docs feel like a beginner-friendly tutorial, but from there you have to figure out everything else yourself, often requiring you to scour the internet and read the source code.

> I have migrated from Jekyll to Hugo for my own website, but the whole Hugo project is just weird. It took me like a year to migrate my simple website because of all the different paper cuts that drained my will to work on it.

My blog's migration anno took only a few days, including a template creation from scratch. My template is still unfinished unfortunately, as Hugo was missing features I needed for my vision back then, and since then I gave up a bit on blogging because of the papercuts mentioned, and the immense timesink that is creating reasonable quality content for publishing. (I do paper-based journalling mostly nowadays since then).

Recently just reviewed the Hugo changelogs since the version I use, and now it knows everything I need to finish up my blog (especially features around images and internationalization were missing, since my blog is not in English, and Hugo used to miss a lot for tiny stuff supporting non-english sites properly, eg. date string localization, sorting for localized tags, like the 'abc' in my language starts as 'aábc', but á got sorted after Z (yes, capiztal Z) if I recall correctly, making localized tags hard to use.). I had some hacks for some in place, but it was tiresome. Now Hugo has all the bells and whistles I need, even more than enough... It is hard to wrap my head around the plethora of features and new concepts. I wonder if the docs cover my usecases, or I'll need to do some Sherlock Holmes stuff once again, to get going...

So the takeaway of this rambling? Hugo is great, it is fast, and by now it probably knows everything one can reasonably need. But man, it is hard to learn, it has become a huge topic, as sitebuilding naturally has its depths, just like any other topic, once real life problems are to be solved with it. The docs? Not great, not terrible. Overall I still recommend it over anything else, as the docs are still okayish for basic stuff. I like it, it is a great project. I love that almost every changelog includes that it got faster a little bit. Atypical for current software project. And it is fast indeed. (experience from a 5 year old release) I have worked with some trendy javascript based web authoring tools at workplace, and man they were all sluggish and had way worse developer experience than Hugo, also their docs weren't better at all. (has nothing to with Js apart from being popular nowadays)

The latest reply in this GitHub issue links to documentation and a example repo showing that tailwind is supported though

That issue should have been closed. This was resolved in Hugo 112. https://github.com/gohugoio/hugo/releases/tag/v0.112.0

Still annoys me to no end that Hugo chose RSS and it requires some song and dance to make ATOM formatted feeds.

Yeah, but... surely, when you were iterating on a post, you were running Jekyll with --limit_posts or doing an incremental build?

I agree, it's a nuisance that a full build can take a while (my own site, which has almost 600 posts plus a bunch of other random pages, takes at least 30 seconds for a full build, if memory serves), but it's hardly a dealbreaker.

It would require full compatibility to be useful. I suppose most users of GitHub Pages don't actually use customization. Gojekyll could be used for building these, otherwise fall back to standard Jekyll.

I believe GitHub Wikis are also rendered with Jekyll? Without customization capabilities on the user side, Gojekyll could be used here, too.

It's really not that slow; my website builds in 0.8 seconds (121 pages) and OP's website builds in ~30 seconds (3,325 pages) – or rather, OP's website can be built in ~30 seconds (see my other comment: https://news.ycombinator.com/item?id=37277381)

All of this is without cache, and with incremental builds disabled; it will obviously be faster with cache and incremental builds.

I don't know where this "Jekyll is notoriously slow" comes from; maybe it was (very) old versions, or maybe it's some plugin people use, or maybe something else, but I've used Jekyll for a number of websites over the last ten years, and I never really had any performance issues.

Certainly today, I think it's unfair to say that Jekyll is "slow". Yes, Go is faster, which should hardly surprise anyone, but for most purposes Jekyll should be more than fast enough, and you'll hardly notice the difference with something faster like Hugo or GoJekyll.

An hour seems way too long; but I can confirm it's very slow. However, almost all of that is in this loop to generate the navigation: https://github.com/danog/MadelineProtoDocs/blob/master/docs/...

If I disable that your project builds in 30 seconds (no cache!) on my pretty old and not very fast i5-8350U, which is roughly what I'd expect for a project of this site. It will be even faster with cache, obviously.

I didn't look too closely, but I'm reasonably sure that can fixed so the total build time will be 30-40 seconds without to much effort; it looks like it's just generating the same HTML every time, so just caching it on the first generation seems like the obvious way.

And sure, Gojekyll is loads faster and more forgiving of these kind of inefficiencies, but "a few minutes" still seems pretty slow, especially considering even plain Jekyll can do it significantly faster.

Some aspects of it certainly are, but it's also one of the more limited templating languages out of the box IMO, and there are several sharp edges especially in conjunction with Jekyll, where it requires you to do all the parsing of what gets passed to a custom tag or filter.

I have 450 posts and about 300 more drafts with Jekyll.

In development it takes Jekyll 32 seconds[0] to do a full build and I've done my best to eliminate as many performance killing nested loops as possible. If I use --incremental it takes about 3 seconds, so my normal writing flow is to split my browser and code editor and I see real-time live reloaded feedback in 3 seconds.

It's pretty good, but some changes require a full build and waiting 30 seconds stinks. If I could snap my fingers and have a fully compatible Go solution that built it in 3 seconds all the time I'd switch without thinking.

Gojekyll isn't compatible with a few plugins I use and switching ~700 posts, a bunch of templates and a few custom plugins to Hugo isn't worth it for my use case.

On the other hand I'm locked into Jekyll 3.X because I can't get Jekyll-Assets to work with any other version so at some point I'll switch but I'm not looking forward to porting that many templates and posts. If it comes down to it I'd probably end up writing a custom tool to convert everything especially since I do custom'ish things with front matter like create a table of contents for each post. It'll require a bunch of string parsing.

[0]: This is on a 9 year old quad core i5 3.2ghz workstation with an SSD.

My team manages several static sites. They're each hundreds/thousands of pages in size. Here's why we like faster builds.

* Fast builds are way more pleasant during development. "Incremental" per-article builds help, but not in all scenarios. Nothing kills my motivation faster than having to wait 30 seconds to preview a fix.

* Fast builds help us avoid jams in our automated push-live systems. Sometimes we have many editors updating pages during a big event. You could consider many different trade-offs when deciding how to manage these queues. But a fast build time erases a lot of those conversations.

We use 11ty on most of our sites. We've found 11ty itself to be fairly performant. The slugs tend to be everything related to processing assets: JavaScript bundles, Sass builds, image manipulation, etc. By streamlining those activities, we can usually get a site build down to just a few seconds.

That said, "instant build" is the dream that animates the best conversations on our team, and we've started building our own static site generator. Our SSG can run both on the server and in the browser. We want our editors in our CMS to be able to get instant, true previews of the page they're editing. Then we want to be able to push single-article builds live, instead of always rebuilding the whole site. It's early days yet. Maybe you'll see it on a "Show HN" some day.

No, plugins are not supported in any meaningful way. With Jekyll I can write "_plugins/foo.rb" and put any code in there to add new Liquid template tags, new features, change behaviour, and even monkey-patch hard-coded core Jekyll code.[1] I can't do this with GoJekyll, because Go doesn't really provide a good mechanism for this kind of thing.

What it does have is a bunch of optional features that are typically provided by plugins in Jekyll[2], but this is a very different meaning of "plugins" that Jekyll has.

[1]: Whether you should be doing this is a different issue, but I would argue that for a static website builder it's fine, especially since you can just lock the Jekyll version with little downsides, and Jekyll doesn't change that often in the first place.

[2]: A list of them: https://github.com/osteele/gojekyll/blob/main/docs/plugins.m...

Once there's feature parity, it'd be great to see more functionality added as first class features so that so many additional plugins aren't needed for seemingly common and basic needs. It's sad that Jekyll development pretty much all but stopped and any wanted features need to get shoehorned in via plugins.

> Plugins are actually supported, but they obviously have to be reimplemented in go.

What are your thoughts on developing a compatibility layer?

If you want "as boring as possible" and "never want to debug" then you probably shouldn't be using Jekyll in the first place; for simple boring use cases all you need is:

  for f in ./posts/*.md; do
      dst=site/$f:r.html
      cat head.html    >$dst
      markdown $f     >>$dst
      cat footer.html >>$dst
  done

Or some variant of that, in your preferred language. There's loads of things you can do wrong in Jekyll even without any plugins, and this applies to most static site generators.

Anyway, I have a list of plugins at [1]; some are as simple as "don't use leading 0 for dates but a space" so it looks nicer (IMHO) but still aligns well, and others are a bit more crazy such as "use Vim's :TOhtml for syntax highlighting because I think Rouge looks horrible".

Stuff like "show all posts with the same tag as the current post" could be done in pure Liquid template too, but this is usually a lot more awkward and a lot slower, and convenience tags like {% warning %}Watch out!{% endwarning %} are completely unnecessary as such, but it's just convenient and nice.

[1]: https://github.com/arp242/arp242.net/tree/master/_plugins

Customised markdown snippets, various semi-dynamic data fetching and preprocessing (eg churning a database into JSON for a front-end), chunking MPA bundles based on the pages, etc etc etc.

Ways to [ab]use SSGs to fulfill your twisted whims are legion.

> The only thing that you will need to do is "bundle install" once your Ruby version is updated, which can be prevented by not updating Ruby. I just locked the ruby version in my package manager as I only use Ruby for Jekyll.

I'm not sure that's a good idea. While you might avoid unexpected updates to Ruby, you'll also avoid security patches for CVEs.

> does not support dates in URLs feature-rich.

If I’m getting what you mean correctly, Zola does support that, look for index transparency, add “transparent = true” to your _index.md, this post explains it for adding “blog” prefix [1] but you can do it with year prefix, then month prefix inside, your folders structure will be years, inside it months, inside it your posts, and your URL will be like this “site.com/year/month/title” (I did the same concept as you can see in these URLs [2]), that, or just write the date in your .md file as in “2023-May-some_title.md” like I did in my blog (empty blog, didn’t yet migrate but it explains it)[3]

[1] https://peterbabic.dev/blog/setting-url-prefix-in-zola

[2]

https://tamim.io/professional_projects/nerds-heavy-lift-dron...

https://tamim.io/resume/tech-stack/

[3] https://blog.tamim.io/2023-april-tbd-migrations

Rust port in 3...2...