In which we wonder why anything else would even be considered.
I’m hoping I don’t have to re-introduce CloudCannon’s Git-based CMS. Suffice it to say it’s real, and it’s spectacular.
I’ve been using CloudCannon’s CMS for almost a month now, as an editor and a writer. Coming from someone whose last web job — marketing, content writing, and site updating for a large university — relied on a 9:1 ratio of end-of-life (and out-of-service) legacy CMS* and pared-back WordPress intranet, it’s been amazing. Working on CloudCannon’s site, I was let loose to do what I do best: creating and editing content. From a content marketing perspective, there’s remarkably little friction involved, meaning I can spend more time thinking and writing and less time chasing down developers. (This is also a great benefit to my developer colleagues.)
All of which is to say I’m comfortable in the system, but I don’t yet know how it all works. And, perhaps just to make it harder for myself, I really want to know. I do know that I could start with a free developer account, and build from there. There’s plenty of documentation available, and it’s all geared to an interested and informed audience of developers. But given that I’ve committed to this zero-exp lifestyle of mine — building from the ground up with no assumptions — it’s probably worth building locally, and pulling the site in to CloudCannon from Github. The appeal here, as I mentioned last week, is that I’ll be able to use CloudCannon’s CMS to branch and merge my edits, and everything I change will be synced to my Github repo.
For a writer who develops — as opposed, I suppose, to a developer who writes — this is a game-changer. (And for a writer who edits compulsively, and has errant daydreams of visualizing the many and varied changes to a single piece of creative work over time, it’s all pretty exciting. I’ve often looked at Ben Fry’s The Preservation of Favoured Traces as a model for visualizing versions of altered texts, and the prospect of seeing a comic or film script evolve along these lines is almost more interesting than actually writing the script itself.)
But before I get anywhere near there, I’ve got one more decision to make.
In which we essentially roll 1d3, with a +1 modifier on future-proofing.
Jamstack.org currently lists 333 SSGs, and that number seems to increase weekly. Rather than be paralyzed by choice I’ll select from three of the most commonly recommended for general use cases: Hugo, Jekyll and Eleventy (11ty). I’ve included a some data below (graph courtesy of GitHub Statistics) showing the commit activity in each; you can also check out their relative growth in GitHub stars.
You can further compare these three in your own time, and for your own specific use case, but a basic breakdown follows, based on a beginner’s scans of their sites and general (mostly Twitter) chat around them:
At a glance:
At a glance:
Apparently Jekyll delivers progressively slower build times the larger a site grows — some reports say “exponentially slower”, though that’s likely an exaggeration. Right?
Jekyll is older. Is it future-proofed? What will I do if I have to move my content off Jekyll?
At a glance:
Aside from general unease about throwing myself into the deep end and committing to one SSG, I’m only vaguely concerned that there’s no standardized or preferred name for this — is it Eleventy or 11ty? Either one, or both interchangeably, depending on my mood?
Most important for me, though, is the prospect of a gentler learning curve. I’m all for slow and steady onboarding. And even though the support for Eleventy may be slightly thinner on the ground than that for Hugo or Jekyll, it’s still there, with a vocal group of proponents alongside.
Hopefully I’ve chosen well.
Next time: Everything gets real, real fast, and I may well bang my head against a terminal window. We’ll see.
* Just how out of date was that (unnamed and remarkably unashamed) CMS? Well, the hiring process for a similar role to mine included finding people who really liked updating sites the same way they did seventeen years ago. It boasted all the worst elements of a dynamic CMS, and was remarkably resource-intensive. Add to that a good decade of accumulated cruft, and dependence upon servers that sometimes wouldn’t update until the following day, iff the wind was blowing from the east and no one slammed the office door next to the server room. Looking back, it’s no wonder I’m sold on Jamstack and static sites.
Part 1: Background | Preamble
Part 2: Git = gud
Edited to add: Hugo’s image processing feature.