E8: Reaching the limits

If you paid attention to my website this week, you’d have seen that I broke something, forcing me to abandon my plans to create a new theme, and revert to a previous version in Git.

I’ve used a static-site generator to power my blog since 2014. For months, I’ve felt I’ve reached the limits of what they can do for me. Then when I refreshed my site’s design in September 2020, I broke the proverbial camel’s back.

On paper static-site generators sound great — write in Markdown, use your favourite text editor, build a site that’s fast and secure, host it for free on Netlify or GitHub pages. These are very appealing features, especially if you’ve ever managed a complex WordPress site with a myriad of plugins that need updating, and are wearied from constant battle against spam and hacking.

When you first start using static-site generators, they feel like breath of fresh air. However, after 50, 100, 200, 300 posts, and the technical debt begins to mount. Build time increases, your GIT repo swells in size, dealing with thousands of individual files becomes a logistical nightmare. It goes from a writing experience to feeling like something akin to managing a software development project.

Pelicans don’t migrate

While I like Pelican, its development isn’t so much as continual, steady improvements but rather the disruption of punctuated equilibrium. Updates break plugin compatibility, and the latest version ditches Python 2.7 support completely.

I’ve thought many times about switching to a more actively developed engine — like Hugo or Gatsby. But that means migrating my content — hundreds of posts — to a different taxonomy system, as well changing the YAML header in every single document. It also means learning new templating languages, which I cannot be bothered doing.

So, despite the openness of Markdown and static-site generators, moving between them isn’t exactly a trivial exercise.

Static-site workflows suck…for writers

Alright, I’m opening myself up for a broadside from the technical community, but hear me out. To post an article to my site, I go through the following steps:

1. Write the article in Ulysses
2. Export the article to Markdown into my git repo
3. Using a text editor, add the metadata block Pelican needs to structure the article
4. Edit the markdown article in Grammarly
5. Make or find a cover image, then copy that to the repo and update the article’s metadata
6. Commit and push the changes to GitHub, and let Netlify handle the build and deployment.

While this worked well works, it’s more complicated than I’d like. Much of my process is given over to management, rather than writing. The laboriousness was one of the reasons why I had to stop my winter world-building series as I risked burning myself out. The command-line tomfoolery gluing everything together also means I can’t publish directly from my iPhone or iPad — I have to do it from my Mac.

Unfortunately, my new theme has broken Netlify’s build process, and for the life of me I can’t figure out why. I could build theme on my Mac without issue, but not in Netlify’s virtualised environment. So now I have the extra step of building locally, then pushing the compiled site to GitHub, and letting Netlify publish it as is. It’s extra work, extra bandwidth, extra bloat in a GitHub repo that’s already pushing a gigabyte in size.

As a content creator, this is how I want my workflow to look:

1. Write
2. Edit
3. Publish

The publishing step should ideally be done with a push of button, and no static-site generator does that for me — not even Netlify’s fancy pants Jamstack CMS.

I want to write more, not less, and my current workflow is really cramping my style.

Beyond static sites

Even if I could improve the workflow, there are still limits to what a static site can achieve by its very nature. I can’t create a membership site and gate content or disable adverts for members. I have to rely on third-party services for comments and automated social media posting. I can’t manage my newsletter directly from my blog.

It’s created a fractured experience for me and my readers, and I’m sick of it.

I should note Netlify offers the ability to expand upon what a static site can normally provide, but boy does that cost you once you exceed the free tiers. You can easily spend more pursuing this option than premium WordPress hosting and the cost of Memberful’s overpriced service.

WordPress?

So, you’re probably thinking its back to WordPress for me after a 6+ year detour into the convoluted rabbit hole of static-site generators. Well, not so fast. I hated WordPress then, and I still hate it now. While I can’t deny its power or ubiquity, it’s still a hot mess of spaghetti code, security flaws and an ecosystem of over-commercialised and overpriced plugins and themes. I don't want to trade one set of technical and administrative debt for another.

Enter Ghost

A worthy alternative, in my humble opinion, is Ghost. Like WordPress, Ghost is an open-source content management system. You can host it yourself, or get someone else to do it for you.

The similarities end there. While WordPress has evolved into a leviathan that attempts to be all things to all people, Ghost is built for bloggers — for writers. Where Wordpress plugins must be written and deployed within the installation itself, Ghost provides a well-documented API opening it up all kinds of inventive integrations. I can publish to Ghost directly from Ulysses, and hook it up to popular automation app, Zapier.

Critically for me, Ghost gives me membership and newspaper management by default. It means I don’t have to pay for a service like Memberfull, or put up with Patreon changing their fees and Terms of Service every five minutes. I can write and manage my newsletter within Ghost, instead of outsourcing that to MailerLite.

In many respects, Ghost offers the workflow and features I want. But it has limitations too. There’s no native comments feature, so I would have to continue using Talkyard, or perhaps something else.

In Ghost, posts are primary, and pages are an afterthought. If I was only blogging, I could live with that, but as an author of grimdark fantasy novels I like to separate and style my book pages from my blog, for obvious reasons. That’s much harder to do in Ghost.

Splitting the site

A possible solution, and one I’ll likely choose, is to divide my site in two. My blog generates more traffic and interest than my books, so I’ll elevate it to my landing page. Because I update my blog regularly, it makes much more sense to use a content management system like Ghost.

I can, and probably will, move my books to a subdomain, and leave them styled in a manner appropriate to grimdark fantasy. Since I don’t change my books much, they can remain on Netlify as static HTML.

This was going to be my approach when I launched my membership site — the difference being I was also going to maintain my current blog as is, in parallel.

I believe now this would be a mistake, representing even more overhead to manage, for comparatively little gain. If Ghost replaces my current blog, I can achieve a lot of efficiency — and that’s ultimately what this is about.

Concluding thoughts

I’ve got some decisions to make and some work to do. I think the time has come at last, to make the switch away from static-site generators and towards something more efficient.

And yet, splitting my site and elevating my blog to the primary position is a big move. While I considered myself an author first, and blogger second, the cold hard reality is more complex, and I make more money blogging than I do novelling. Does this admission mean I’ve shifted my focus to become a blogger first, and a novelist second? I guess I can wear multiple hats, but perceptions are important — not least my own.

If you have thoughts, I’d love to hear them, even if you think I’m bonkers to switch from a static-site generator to Ghost.