My issue with Hugo was that it just wasn't reliable with what was in the cache so I could never trust whether what I saw was actually the state of the site and causing me to push a broken state to the remote server. Hugo is great if it works but I found it a nightmare to deal with when it doesn't.
There are countless options in Hugo (yes I understand it's powerful but I rather it just had half the option and they work as advertised), some of which at times are contradictory so searching for solutions took me ages. I have no affiliation with the zola project and am not even big on Rust. Zola just worked for me and seems a lot less "hacky" than hugo thanks to the Tera templating system.
The Author of Zola writes on his github:
> [hugo] personally drives me insane, to the point of writing my own template engine and static site generator.
a sentiment that I share very much.
Hugo was a lot harder to learn, the template engine from Hugo felt very strange for myself coming from Django, Twig and the Jekyll template engines. The template lookup order is complex and for small website this complexity is unnecessary.
When building a large website (kde.org has more than 1400 pages) all these features make sense. I can organize my template in directories, enjoy fast generation time, separating the templating part from the content, create SCSS files for each pages that needs a special layout. There is also a (fast) JS bundler integrated into Hugo. Afaik Zola also doesn't support i18n and Jekyll has a few plugins for that but this is not a build-in functionality.
I settled on Hugo because it ticked all the boxes and even had org mode support.
The next three nights were horrible. I'm a professional web dev, full stack, I've used dozens of langs, frameworks, probably hundreds of tools. It took me three nights to set up a basic home page for an academic CV and some publication lists. Nothing more. And even then the whole thing was wonky and super unreliable for inscrutable reasons. Big red flag.
I was angry and frustrated, and I started doubting myself.
So I pulled the plug. Tried Zola, I was done in 1.5hrs. Start to finish, just done. Zola is great.
Hours and days struggling with getting Hugo to do what I wanted until I gave up and had a Jekyll site up and running exactly how I wanted it within a few hours.
Who cares about saving 5 seconds site generation time when you lose days pulling your hair out just trying to get the damn thing to do what you want?
I've never felt that site generation time has been a problem for me, although I've only worked on things with 10s-100s of pages, not thousands... But then part of me wonders who it is out there who is doing site-wide updates to x,000 page sites who needs it to happen in 2 seconds? What kind of workflow on a site of that scale can't wait 30 seconds?
That said, Hugo is the only piece of software I remember that makes me feel stupid.
It must be a awesome if you use it frequently, but I only make changes to my sites maybe once per year. I often struggle for hours to make simple changes or to figure out why it's not working. Two examples:
Sharing the feeling of others in this thread and happy to discover Zola! :)
It's already got lots of plugins, but it's fairly easy to add your own as well. It's in the mature / complete category of projects in my opinion (although there's still some development happening)
One thing that's nice about having dozens of actively-developed static site generators is that if you don't like one you'll probably like a different one.
Zola is less powerful, but does the job and feels much more stable.
Did you report these bugs anywhere? Can you be more specific? What were you caching?
If you're caching partials for example, you need to make sure you provide correct caching keys so are you sure it wasn't misuse?
The “disable fast renderer” option (for local development) is indeed a must have, or weird things happen indeed.
My students also found the documentation difficult to grasp in particular regarding the content types and related features (section, bundles, archetypes, ...).
I actually like go templates, so it was never an issue for me.
but IIRC not all of its image features were available in the theme's zola port
Just when you think you've handled every edge case, you have to account for screen pixel densities, better ways to infer sizes and srcSet attributes on picture tags, browsers with or without modern features for loading images in better.. it's no small task!
(I'm obviously biased but I think Gatsby's solution is pretty good now)
Can you explain this a bit further? Why would what is/isn't in the cache cause issues? I must be missing something here. I have used Hugo before but not sure what this means exactly.
I love Hugo and how fast it generates my business site (https://sunboxlabs.com), but having just hired a first (non-technical) writer I had a classic dilemma: either teach them the Hugo command line/markdown or switch to something like Forestry/ButterCMS/Wordpress for a non-technical CMS.
Then I found https://NetlifyCMS.org: You just add an /static/admin/ folder with two files in it and BOOM: non-technical users can create and edit posts with a Wordpress like dashboard (saves as Markdown to Git still). Strongly recommended.
At that point (once we've checked the links and typos, etc) we flip the draft boolean to false and check the article looks as expected on production.
Not perfect – we'd probably have a staging server if we were bigger – but we're still small :)
Nothing's perfect though, I just find most static site stories don't address the above so any thoughts are appreciated!
Also, has the entire kde.org website migrated to Hugo or is it only the Announcements section? The RSS feed linked in the post is for the announcements section alone. More clarity on this in this blog post would be good.
The entire kde.org website migrated to Hugo. Previously only a very small part was using it (< 10 pages) and this was quite helpful to test if everything worked before porting the rest of the website.
Build times went from 10 seconds to 0.2s.
I don't love the template language but once we've coded blog post pagination, head tags, image optimisation etc. it's rare you need much more.
Did you mean "from Jekyll to Hugo" instead?
Why is it only Dutch which is capitalized? I'm genuinely curious (my English is not perfect, perhaps there is a rule behind this I don't know).
I needed i18n (internationalization) with unique per-language routes (as is described in this article). I tested Hugo but ended up going with Gatsby. I'm happy with the result - adding a new language now is just adding another .json file.
We like it, but there breaking changes from time to time - especially if you only have a small team building the site, I was using a 4y old version until I did an upgrade in one go.
For purely static sites, there is nothing better than Hugo imo. Next.js comes in at a close second, and is really handy when you need more than just a static site, but man I can't say enough good things about Hugo.
Jekyll, to me, is a DIY tool; it's clunky and obscure and you only make it happen with your pliers and your hammer -- you can achieve nice little projects quite fast, but once you go for a more elaborate structure your work starts falling apart.
Hugo is more like a construction company with very-well organized architects. Its logic is relentless, yet it is an incredible powerful tool once you master it -- and honestly the video tutorials by Mike Dane and documentation at gohugo.io are really well-made and if you're switching to Hugo, you should dedicate one day to watch the courses and RTFM.
The quality of the template from which you start might indeed be very determining of future success/frustration. Just don't rush it, you'll get there.
Now, I'm surprised Markdown is often chosen over Asciidoc. Especially for larger website like KDE.org; it seems you'd want to use a markup language that is more standardized than MD.
Good to see RSS is still being added to websites in 2020!
Does anyone else get an almost visceral feeling of disgust most applications (or even words) that use K instead of C, or add a K just to fit the KDE motif?
I really want to like KDE, but there is something stylistic about it that drives me up the wall. I'm asking not to insult anyone, but to see if anyone has an explanation of why I react this way. Maybe it will remain an unexplained idiosyncrasy.
It's largely a relic of a time before interoperability-enabling standardization via freedesktop.org specs, when "k = will work well with your desktop" had much more utility to users. The Gnome crowd did the more or less the same thing with g, and also stopped.
As others mentioned, plenty of other tech orgs have pulled branding moves like this, be it iSomething or "My Foo", and arguably those provided less actual utility. I would argue this should affect the relative levels of irksomeness. :-)
Ah, found it. This one: https://invent.kde.org/websites/kde-org
I have similar python scripts as the OP, that handle generation and pre-processing of markdown files which then get used by Hugo. It feels hacky and something extra to ship.
Is there a way to extend Hugo or build add-ons to include custom functionality?
I used it to generated link to the API documentation directly from the Doxygen tags files: https://invent.kde.org/documentation/develop-kde-org/-/blob/.... This is quite verbose but in the end it allows me to do things like this: `[Action](docs:kirigami2;Action)`. This is visible on develop.kde.org, the other big Hugo project in KDE.
GIT_WORK_TREE=..../example.com git checkout -f
Learned from a few sources (shout out to Dreamhost for my original intro to this idea), but here are some relevant readings:
But in the footer there is "Powered by Jekyll with Type Theme". Hm...