Comment on Simple Blog options?
manxu@piefed.social 5 days ago
I ended up with Hugo, a git repository, and a cron job for the build. I write an article, check it in, the server picks up the git change and rebuilds the site. What I like about the setup is that the server only has the binaries hugo and git, and a shell script for the rebuild. Also, I write in Markdown, add media to the git repository, and articles are published soon after I check in without any remoting on my part.
I did look at WriteFreely after the setup, though. I find the minimalist design very beautiful. Didn't switch to it, but may look at it again for another project. https://github.com/writefreely/writefreely
sxan@midwest.social 4 days ago
Hugo has a watch mode, right? It should rebuild if it detects changes.
manxu@piefed.social 4 days ago
Hugo watch mode (both server and build) does not produce accurate sites on change and is really meant for development. I find after a developing for a while, I have to kill the process and restart it and then things are "fresh"
From reading the documentation, I strongly have the impression that hugo focuses on being fast on re-render and that the idea is to build and deploy to public site each time there is a change. The big difference is probably whether to render locally and push the generated content, or to push the source markdown and render remotely (which I chose).
sxan@midwest.social 4 days ago
Ah, Ok.
I do as (or a similar workflow): I rsync the content directory and let Hugo on the server render. My sites are public, but perhaps they’re just much smaller or not as popular; Hugo renders even my largest site in about a second, but for a large, slow, heavy-use production situation I could see a push-and-swap process for a more atomic site update.
I don’t see the degradation you do, but there are so many possible variables.
My biggest gripe about Hugo is how limited it is in supporting source document formats. There’s no mechanism for hooking in different formats, and the team is reluctant to merge PRs for other formats. When I started with Hugo, I had a large repository of essays spanning a decade and written in a variety of markup, from asciidoc (which I used for years), to reST, to markdown; and markdown is by far the worst. I was faced with converting everything to markdown, which was usually a lossy process because markdown is so limited, or not publishing all of that history. And now we have djot, which is almost the perfect plain text markup language, but I again have to first do a lossy conversion to markdown to get Hugo to consume it. It low-key sucks, and I’m actively looking for an alternative that has a more flexible AST-based model for which new formats can be added; something that consumes a format like pandoc’s AST.
manxu@piefed.social 3 days ago
Did you look at Pelican? I share the frustration with much of Hugo's infrastructure: the template language is buggy and inscrutable, and the plugin architecture wanting.
I ended up with Hugo, but I considered Pelican. It uses standard Jinja templates, which I find much more rational (but it might just be me) and I recall there were plugins for a lot of things, including different source formats. The code is written in Python, so that even if there isn't a plugin for a format you need, there probably is a Python library for it and it should be relatively easy to make it a plugin.
Crap, now I want to switch to Pelican...