Each entry in the “Gems in the rough” series is a collection of tips, explanations, and/or idle observations which I hope will be at least somewhat useful to those of you with websites built by static site generators (SSGs).
I think this is probably the earliest in any month that I’ve ever gotten to five posts. Not that quantity equals quality, to be sure, but just sayin’. So, while I’ve been spending most of the month so far in Hugo-related posts, what else has been going on in SSG-land?
Since the Eleventy SSG became his full-time role, Eleventy creator Zach Leatherman has been busy with a number of enhancements to the project. One in particular is the need to replace Browsersync as Eleventy’s built-in development server, due to that package’s serious security issues. I had expected he would simply pick a different one, but—“Sha-zayum!”—he’s come up with one of his own. The only thing is: to adhere to SemVer guidelines, it’ll require a new major version; so, not long after Eleventy reached v.1.x, it’ll soon be going to v.2.x.
What does this mean for existing Eleventy-based websites? Leatherman says only those sites with specific needs for (and/or ties to) Browsersync code should need fixes for breaking changes—and, for those instances, he’s cooking up a plugin to let such sites continue to use Browsersync even with v.2.x. Other Eleventy sites should transition nearly seamlessly to the new server. Of course, that’s what testing is for, so we’ll see how that goes; but everything looks very promising at this point.
Leatherman announced these upcoming changes and demo’d the new dev server in his most recent weekly video for the Eleventy YouTube channel—something else for which he has far more bandwidth now that he’s all-Eleventy, all-the-time.
As of the initial publication of this post, I’m trying a commenting system called giscus. It’s based on Utterances. Both rely on GitHub APIs. While Utterances uses the Search API for GitHub Issues, giscus uses the Search API for the newer, more feature-rich, and seemingly more polished GitHub Discussions.1 (Of course, these projects’ dependence on GitHub also means that, as of now, each use thereof requires a GitHub login. Indeed, I couldn’t even find the word guest anywhere within the GitHub Discussions documentation.)
Back in 2020, I did a post about commenting options for static sites (and one of those mentioned was Utterances, which inspired giscus). I chose not too long after that to go to my current reply-via-email setup, because I read on another fellow’s site that he did it that way because2 he found such interactions with readers were more meaningful. Since, I’ve found this to be true on my site, too. That said: if you’ve read enough of my stuff, you know that I’m always attracted by Shiny New (or sorta New) Things, so I may just give giscus a look-see.
. . . and so I am doing just that. I had one commenting system or another on my site for about two years until that change last year and, now, here we are again—at least for now.
To be sure, I’m not taking away the reply-by-email button/link, which will stick around regardless of what I decide long-term about continuing with giscus. In the meantime, you have two ways to react to each post. Your faithful correspondent always welcomes your thoughts.
Note: Because of giscus’s reliance on the existing GitHub Discussions feature set, there currently is only one level of nesting; so, if a thread gets “heavy,” it may not be readily obvious who’s replying to whom.
A follow-up to something I mentioned a few weeks ago: the nice folks at CloudCannon kindly asked me to write another piece for them, and the latest such effort is now live on their blog: “The Ultimate Guide to Hugo Sections.” As I subsequently noted in a reply to my retweet of the article’s original announcement:
That said, I share their hope that the article will clear up some of the seeming mystery around these particular aspects of web development with @GoHugoIO.
And there’s more to come in the near future.
Commenting by giscus.