Comment on Simple Blog options?

• manxu@piefed.social ⁨2⁩ ⁨months⁩ 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).

  source

  • sxan@midwest.social ⁨2⁩ ⁨months⁩ 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.

    source

    • manxu@piefed.social ⁨2⁩ ⁨months⁩ 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...

      source

      • sxan@midwest.social ⁨2⁩ ⁨months⁩ ago

        Did you look at Pelican?

        I have not, but I will. I may also look at Zola, although it, too, appears at the surface level to be tightly coupled with markdown.

        the template language is buggy and inscrutable

        It’s just Go templates, which are pretty solid; I’d be surprised by any bugs, unless they’re in the Hugo short codes. The syntax is challenging, even if you’re a Go developer and use it all the time. It’s a bespoke DSL, and a pretty awful one: it’s verbose, obtuse, and makes some common things hard.

        Go is my language of choice, but my faith gets shaky whenever I have to use templates.

        I’m not a huge fan of Python; despite its popularity, it’s got a lot of problems, not least of which is the whole Python 2/3 fiasco; which, years later, is still plaguing us. However, if I can containerized it so it isn’t constantly breaking in the background when I do a system update, I’m not opposed to using a project written in it. At least it isn’t Node; I won’t let that crap onto any server I admin.

        source