Comment by uncomputation | Hacker News Reader

Comment by uncomputation | Hacker News Reader

Yes, this one million times over. I have went from home-rolled React to Jekyll to Gatsby to Hugo and now seriously considering just doing my own HTML/CSS. Practically, I have rarely run into the issues other markup languages and SSGs are supposed to fix and more often, I find their constraints actually limiting/complicating my fairly simple desires. If I want to add movie/album reviews, rather than just making /reviews directory with some files and some basic CSS, I get stuck thinking about Hugo "archetypes" and templates and _index.md and layouts and all of this baggage. I wanted to add support for my site to use my custom "CSS as S-expressions" parser [0], but got turned off by the idea of integrating Hugo "pipelines" or "assets" or all of that. Not to mention that this grows ever more overwhelming if I take a months-long break and have to Google how to start my own blog server! Then I look at RMS' site and, ugly as it is, it has held up and looks way easier to update and less constrained by any premeditated structure/hierarchy.

[0]: https://uncomputation.net/cascading-style-s-expressions/

RSS.

If you're writing a blog, then you probably want a way for people to subscribe to it instead of making them visit your site manually. Unless you are confident that you not only CAN write a feed by hand, but will never forget to hand-update it after updating the post itself, you're going to want to at least have the RSS feed be auto-generated.

And once you've added the infrastructure to auto-generate the RSS index, there's very little point in not auto-generating the HTML index, too. If only because, that way, you won't forget to run it.

labs.steren.fr is pure static HTML, https://labs.steren.fr/atom.xml is manually updated and it doesn't take me more than 1 minute per article to do so.

I know how to write XML by hand. It's not hard. The reason I use Jekyll instead is because updating the RSS feed is something I might forget to do at all. Before I used Jekyll, it was a custom Perl 5 script, and if GitHub ever stops supporting Jekyll, that's what I'd move back to.

A well-designed SSG, like all of the ones I've used, will interlock[1] updating the feed and the HTML. You can't easily update one without updating the other, just like you have to go out of your way to open a microwave oven without also turning it off.

[1]: https://en.wikipedia.org/wiki/Interlock_(engineering)

>> my custom "CSS as S-expressions" parser [0]

That’s a pretty neat idea, if all CSS on a site originated from your s-exp’s then you’d make it trivial to find not just what, but why a particular style has been applied (because now you’re only looking in an acyclic-graph, it’s easier to search).

Thanks, yeah this is actually related to/the first step in a similar idea I had for a CSS SAT solver which generates a set of minimal CSS rules.

Have you tried Jekyll? I don’t know Hugo; I like Jekyll because it’s very simple with very little abstraction. My blog is just some hand-written HTML with liquid templating. I like how you can add any metadata you want to a post/page and then use it in your templates.

Jekyll was literally mentioned in the second sentence. You may have missed the point of the comment.

I have various static sites that I maintain, I recently added a new site created in Jekyll and wrote a bunch of content for it.

While I like Jekyll and I'll continue using it, I can definitely relate to the frustration when first using it. I get this feeling that I already know what I want Jekyll's HTML to look like, and now I need to work backwards and develop an understanding of Jekyll in order to figure out how to get Jekyll to produce the desired output.

By "HTML" I don't actually mean that I have a problem with embedding specific markup in the page, it's stuff like putting the files in the right place, getting the template to contain the right material, etc.

And to be clear, I'm going to continue using Jekyll since it seems more practical than e.g. Hugo given my constraints / available resources / etc, and I may even migrate some other sites I maintain to Jekyll, but Jekyll, like other static site generators, seems to throw a lot of mess in the way of simple desires, as the parent comment articulates.

this is probably the best chance I'll get to plug this on HN: https://github.com/mivanit/pandoc-sitegen

It's a truly dead simple static site generator that uses pandoc to turn the markdown into HTML, and mustache as the templating language. It's about 400 lines of actual code total. It doesn't include an actual server, it just converts your markdown files into HTML. It's by no means finished but I use it for my personal website.

Perhaps try picking a simpler SSG like Pollen or Pelican? I've been fairly happy with the latter.

I've found it hard to resist the conclusion that "Hugo sux".

You get out of it what you put in to it, so to speak.

It is very easy to over complicate things but it is also easy to use it for lightning fast static page generation focusing only on letting it manage the head and global page structure.

I put quite a bit into a project with Hugo and haven't gotten anything out yet.

I expect to try at least one other static site generator before that project is done. To be fair I am very interested in a Python-based generator because I have a whole lot of visualization code in Python that could be cut-n-pasted into one.

Reply on news.ycombinator.com