Blog On

By Serdar Yegulalp on 2019-03-27 17:00:00-04:00 No comments

For the sake of documenting another project I've recently resurrected in the background, I sat down and toyed with the Pelican site generator. Mercury, the system I wrote to run this blog and a couple of others, isn't in danger of being displaced by it any time soon; I'm just curious about what else is out there. But the basic principle it uses is the same as mine: generate static HTML, stuff it somewhere, and regenerate only what you have to when something changes.

Many of the more technical bloggers out there have given up on WordPress or hosted solutions like Svbtle or Medium, the former because it's WordPress and the latter because they're not owned by the end user, and moved to static HTML generators like Pelican or Nikola. I think if I had been making the switch away from Movable Type now instead of a few years back, I would have gone with something like Pelican, if only because its feature set now is a lot closer to what I need than what it was then. But a lot of the workflow I have is best served by what I've already created, so I'm not touching anything on my main sites just yet.

The other reason I didn't pick up on Pelican was a feature that's touted as an advantage, and which I can see as one, but to me was a long-term barrier: no database. Everything is stored as flat files. That's useful, and it scales reasonably well for small-scale personal blogging, but it means anything more ambitious than a simple search-and-replace operation on a couple of files becomes cumbersome. SQLite and full-text indexing have proved to be immensely useful in more than a couple of circumstances, especially with something like 3,000+ posts on this blog alone.

I know, I could probably emulate the same effects using grep and a few carefully crafted regular expressions; the point is, I don't have to. I've got years of content in here, and I decided a while back that using a filesystem as a database for it was a step back, not forward.

One feature I did have on the "to-do" list for Mercury was the ability to have any resource in the system, like a post or a template, backed by a file somewhere. That way you could have the best of both worlds — you'd have the database when you needed it, and the convenience of files on disk when you needed that. But I never got around to implementing it, in big part because the use case never manifested for me. I don't find the lack of files-on-disks to be all that terrible, especially since I can snag a copy of the SQLite database any time I want and dump it out.

On the whole, I am really fond of Pelican and its fellow apps. My main problem is I don't want to toss my existing workflow for what amounts to the same benefits I already have, and a few losses. I'm leaving the door open for now, though.