Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
just-the-docs
A modern, high customizable, responsive Jekyll theme for documentation with built-in search.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
gutenberg
A fast static site generator in a single binary with everything built-in. https://www.getzola.org
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.
You are only able to only use partials in HTML pages and shortcodes in Markdown pages. Why? They use 2 different syntax, so the best you can do is awkwardly wrap a partial in a shortcode. What's the point? They serve basically the same purpose.
Want to set up RSS? Oh yeah, for some reason by default it will not show full content in your feed reader, instead only a small extract with the only way to fix it is by making your own template[1]. But wait, why are we using RSS instead of Atom? Who knows, but if you want to use Atom, you have to use your template and insert some stuff to your config.
Also don't look at the bug tracker, that thing is frustrates me to no end.
You of course have the everyone's favourite Stalebot that you might have noticed in my previous link, but if you look at older issues, you will see the maintainer self-botting as a Stalebot[2][3] for some reason.
You will also see the maintainer moving issues between milestones for years with no end in sight[4].
Changelogs can sometimes feel a bit, odd too:
> but also a big shoutout to @dependabot[bot], […] for their ongoing contributions.
And commit messages sometimes are just… a bit too long[5] (it is truncated by GitHub, you can append .patch to see the full message).
Their documentation is awful to read too[6]. Oh and the templating engine? Yeah, not documented at all. Also the quick start guide will tell you to git clone some random theme, but I don't want my website to look like someone's, I want to write my own styles and have my own structure, but they don't really tell you anywhere how you should go about it. Because of it, I would search GitHub to sometimes find answers on how to do some stuff, but you would quickly find that most people had no idea how to actually use it. For example you can find a lot of people making opening and ending partials to have a common page layout instead of actually using the built-in Hugo layouts.
So why have I bothered switching? i18n support, so far out of all SSG I tried, Hugo does it in the least painful way.
[1]: https://github.com/gohugoio/hugo/issues/4071
[2]: https://github.com/gohugoio/hugo/issues/385#issuecomment-283...
[3]: https://github.com/gohugoio/hugo/issues/1035#issuecomment-28...
[4]: https://github.com/gohugoio/hugo/issues/448
[5]: https://github.com/gohugoio/hugo/commit/6dbde8d731f221b027c0...
[6]: https://news.ycombinator.com/item?id=30527884
No, plugins are not supported in any meaningful way. With Jekyll I can write "_plugins/foo.rb" and put any code in there, and even monkey-patch core Jekyll code.[1] I can't do this with GoJekyll, because Go doesn't really provide a good mechanism for this.
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 it doesn't change that often in the first place.
[2]: A list of them: https://github.com/osteele/gojekyll/blob/main/docs/plugins.m...
Context is everything. In the context of Jekyll, all of this is certainly a useful feature: this is not code that needs to be re-used or maintained in the same way as your Rails project has to be.
As always, engage your brain before doing anything and you don't need to use these features, but it gives you the tools to do "smart things" that Go simply can't. This, among other things, means that Jekyll will scale reasonably well with your website as your needs grow, without having to add features to Jekyll core, using your own fork of Jekyll, or switching to something completely different.
For example, I have a little plugin[1] to work around a bug[2] and to skip the hard-coded requirement to have a date in the filename.[3] Is this ugly? Yes. Is this fine to generate a relatively simple personal website? Also yes.
[1]: https://github.com/arp242/arp242.net/blob/master/_plugins/no...
[2]: https://github.com/jekyll/jekyll/issues/8707
[3]: https://stackoverflow.com/a/68287682/660921
I think GitHub Pages only supports a whitelist of plugins, so you might have some more difficulties solving it well without any plugins. I use Netlify for my site, which does support arbitrary plugins.
One quick way to make it faster is to include that "_includes/nav.html" only in a nav.html, and then use an iframe to load that on every page, or something like that.
Anyway, I'm not the first to notice this it seems, although even "twice as fast" would still be quite slow: https://github.com/just-the-docs/just-the-docs/issues/1323
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.
Context is everything. In the context of Jekyll, all of this is certainly a useful feature: this is not code that needs to be re-used or maintained in the same way as your Rails project has to be.
As always, engage your brain before doing anything and you don't need to use these features, but it gives you the tools to do "smart things" that Go simply can't. This, among other things, means that Jekyll will scale reasonably well with your website as your needs grow, without having to add features to Jekyll core, using your own fork of Jekyll, or switching to something completely different.
For example, I have a little plugin[1] to work around a bug[2] and to skip the hard-coded requirement to have a date in the filename.[3] Is this ugly? Yes. Is this fine to generate a relatively simple personal website? Also yes.
[1]: https://github.com/arp242/arp242.net/blob/master/_plugins/no...
[2]: https://github.com/jekyll/jekyll/issues/8707
[3]: https://stackoverflow.com/a/68287682/660921
another good one thats even smaller:
https://github.com/piranha/gostatic
This project uses another templating language, apparently based on Shopify.
(1) https://github.com/osteele/liquid
There is always https://github.com/traefik/yaegi - a Go interpreter written to make it easy to write plugins.
I'm currently learning https://www.getzola.org/.
It's more manual than idy like but it's gonna be for a small personal and work website so I don't mind much.
It's super fast.
Doesn't seem to fit your use casr but still.