← Back to context

Comment by azangru

4 days ago

Did he reinvent a static-site generator? Markdown, pandoc, makefile... Sounds like a job for hugo/eleventy/jekyll/whatever.

I don't maintain a blog so my opinion may not count for much, but I feel like if what you are trying to do doesn't fit neatly into an SSG's existing templates/themes, it may in fact be easier just to use pandoc and some simple tooling around it. Certainly when I looked into a few SSGs for the purpose of making a simple personal website (without a blog) I found I would spend more time trying to bend them to my will than just writing what I want in markdown and running pandoc on it.

  • Most of them bend to your will very easily if you are the one writing the HTML and not trying to use an existing template/theme. Even Jekyll the "themes" are optional and you can entirely ignore them.

    Also most of the complexity disappears if you aren't trying to make a blog. They generally all have "simple pages" support that is much simpler than trying to figure out their blog mechanics.

    Of course the hard part is picking an SSG you like, and it is easier to just build your own which is a big part of why SSG proliferation happens. Too many options? Make a new one.

    My main sites are still in Jekyll for now, for historic reasons of GitHub Pages support.

    My latest discovery and new love in this space is Lume [0]. It's definitely on the simpler side of the scale. I haven't tried it for a full blog yet, but the simple website I have built with it has indeed continued to feel simple throughout the process and even using some of the features Lume's documentation labels "Advanced".

    [0] https://lume.land/

Its the the first time someone has reinvented a static site generator...

Looks around sheepishly

I've tried Hugo and Jekyll a few times and they are pretty complicated. If you just want to post something online every now and then, then it might be easier to just to HTML.

  • Alternatively pick a light-weight template engine from your favorite language and use it to generate the html. More flexible than plain html files and very low learning commitment.

    I've been doing that for years and really happy with the result.

In my opinion, Jekyll is easier and more capable than Pandoc and markdown files for a HTML/CSS website.

Jekyll also has a higher ceiling than Pandoc when you need a templating language, plugins, etc.

Another way of looking at it is that Hugo, eleventy, etc. are reinventions of pandoc, makefile etc. The latter things came first!

  • I would rather say that the former group are wrappers around the latter group. Using an SSG doesn't just mean converting Markdown etc. source and orchestrating a build process of some sort, but also filling in templates and providing useful build steps to orchestrate (such as generating additional pages that reference the actual article content: archives, collections grouped by tags or categories, etc.). They also generally implement things like the live reloading that the author mentioned as missing.

    I'm currently using Nikola and have done quite a bit of customization - by hacking around and learning modern web stuff as I go (the last time I did this stuff seriously, jQuery was dominant and Bootstrap was brand new - of course I'm not writing a bunch of JavaScript for a blog, but that also presumably dates my understanding of HTML and CSS). I've found that even though there's way more stuff in here than I really want, it's really nice to have that kind of scaffolding to start, and I can strip it away as I customize.

Yeah, obviously this is literally what something like Jekyll or Hugo does. It's just (at least to me) a simpler version of that where you can fully see what's happening. Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.

  • >Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.

    I didn't like how complex that stuff is with Nikola - I didn't have an obvious entry point for making the kinds of customizations I really wanted, and yet there was still so much to look at in order to understand the system. But at the same time I really didn't want to spend hours re-learning CSS more or less from scratch, when I could actually use the examples already in the existing themes.

    I did something really awful: instead of trying to make yet another layer of theme "extension", I copied everything locally and have been condensing it as I go.

    This had the benefit that I didn't have to decide on a bunch of CSS classes up front in order to have anything look passable. There may be tons of unused stuff, but I'm cleaning that up as I implement my own things - and bit by bit, I get something smaller and more comprehensible that fits my mental models. This conversion process might not be any faster, but I'm certainly enjoying myself more.

    At some point in the future I'm considering doing a simple templating engine and converting these templates (originally Mako) to it. It just irritates me that I still have to deal with close tags - both in HTML and in template directives - when I'm doing everything in Python. I have a vague memory of a 2010-era JavaScript templating system - I think it was called Express or something like that? - which used indent-based syntax without closing tags. So I'm inspired by my recollection of that.