Simplify, simplify

General note: This site’s appearance, configuration, hosting, and other basic considerations will change over time. As a result, certain content on this page could be at variance with what you’re currently seeing on the site, but the two were consistent when this post originally appeared.

Our life is frittered away by detail. Simplify, simplify.
— Henry David Thoreau.

A few days ago, I explained that I was simplifying the site’s look-and-feel. That seemed plain enough, I’m sure.

There was more going on behind the scenes, however.

Story time . . .

It’s been about two-and-a-half years since I first launched this site. It’s been closer to three years since I began research into how I wanted to maintain it. That process ended with my choosing to go with static site generators (SSGs) in general and the Hugo SSG in particular.

Not quite a year after that, I reexamined the Hugo choice because I had what the Kewl Kids used to call “FOMO” — Fear of Missing Out. I figured I’d gain more potentially marketable experience by using an SSG based on JavaScript rather than the Go-based Hugo, especially given that most of the hotness in the world of SSG development seemed to originate from JavaScript-based SSGs.

That led me to not one, not two, but three tries of Gatsby. There also was an initial short try of, followed by a longer engagement with, Eleventy.

Sprinkled in between that short try and longer engagement, not to mention the dalliance with Gatsby, was a brief return to Hugo that was spurred in part by a distrust of all the Node.js dependencies that power both Gatsby and Eleventy. This is as opposed to Hugo, which is a single-binary executable — in plain language, an app.

Nonetheless, I enjoyed JS-based SSGs in general and Eleventy in particular, so I buried such thoughts in the back of my mind and went on my merry way, figuring I’d finally fought the issue to a conclusion.¹

Then, starting in the spring of 2020, I had occasion to deal with Hugo once again.

In April, I wrote about incorporating webmentions in one’s Hugo-based website. It was part of a five-part series about webmentions and SSG-based sites, and the research I did for the Hugo-related part allowed me to notice anew some of Hugo’s advantages.

In July, as part of creating some SSG starter sets, I made two for Hugo, and once again found myself enjoying working with Hugo more than I’d expected.

Intrigued by the “what-if” ideas now swirling in my cranium, I thoroughly updated my old Hugo repo, including spiffing it up with themes for both Tailwind CSS and SCSS. I even used it to run this site for a few weeks. Nonetheless, I then switched the site back to Eleventy, figuring that’d been enough of that.

As 2020 neared a merciful end, two things happened that made me re-think that judgment.

Thing One: a wacko repo

One Saturday morning, spurred by curiosity about cache-busting static assets in Eleventy (more on that in Thing Two down below), I began to work once again with the webpack-based Eleventy repo I’d abandoned earlier in the year. Since it had been months since I’d updated all the dependencies, I ran the usual sequence of npm commands to accomplish that, and then ran npm run start so the repo would create a dev-mode version of the site.

Or, at least, I’d hoped it would create that. Can you say, “lots of breaking changes”?

Now, this glitchiness was no shock. Among other things, the update took the repo from webpack 4 to webpack 5; and that, alone, accounted for most of the FUBARing. However, quite a few other updated dependencies were equally screwy. I had been prepared to fight a handful of such issues but not a whole host of them, and particularly not in view of my simple lack of knowledge of how to do so.

Slowly, it dawned on me that this was what eventually would happen to any of my repos built on Node.js dependencies, even those with which I did work actively.² And I began to wonder about how much I wanted to keep fussing with all that.

Then I found a Hacker News thread from nearly a year ago about an article, “Ride Down Into JavaScript Dependency Hell,” and in that thread were plenty of comments that sounded a lot like what I was thinking (these are edited only for style and/or spelling):

• “Every separate package adds overhead and another maintainer that you’ve got to put your trust in. I’d rather have few packages of well-trusted maintainers instead of a thousand packages from God knows who.”
• “I have a project with a total of eight dependencies. I walked away for six months as it was stable. I come back to add a few features and npm tells me I have over 38,000 vulnerabilities of different severity levels. So many that npm audit just freezes up.”
• “These types of issues are the biggest reason why I avoid JavaScript/npm projects. I came back to a project after a few months and it was broken; had to rewrite some parts and upgrade other parts just to get it to run again.”
• “I’ve had several apps that can basically never be upgraded due to complete insanity deep in their dependency trees. I’m pretty cautious about third-party dependencies, but some of those libraries’ libraries are not, and it’s really hard to see that coming.”

And, of course, there’d once been the infamous left-pad incident which, while mitigated quickly, constituted a cautionary tale of major proportions about packages that were, themselves, giant collections of packages.

As I considered these things, a little voice in my head periodically whispered, Ya know, you wouldn’t be worrying about these things if you were still using Hugo.³

I soon found myself ruefully recalling my own assessment at the end of “Why I’m staying with Hugo,” the chronicle of my initial foray with SSGs from the world of Node.js:

. . . the extraordinarily bright people behind [JavaScript-based SSGs] . . . all need to think about the dicey interaction between all the dependencies and frameworks and other stuff on which their products rely. It’s like trying to balance a chair by one leg poised on a tightrope. One little breeze and, crash. No, thank you.

Thing Two: asset pipeline envy

One particular Hugo functionality I not only rediscovered but also learned more about during that run-through last fall was Hugo’s built-in asset pipeline, Hugo Pipes. This came to the fore for me after I became more aware of the need for cache-busting static assets. This is something Hugo can do out of the box, while Eleventy has no asset pipeline and therefore must accomplish this through other means.

I spent three separate articles on this subject of cache-busting CSS in Eleventy. Although I finally managed to come up with a mostly satisfactory solution, I once again found myself musing about how ably Hugo, on its own, handles this and so much more for which a Node.js-based SSG needs to depend on, well, tons of dependencies (and, even then, can’t always do what Hugo can do).

The result: thoroughly Thoreau

After several weeks of these and numerous other considerations, I realized that what I wanted most about maintaining this website, over and above all the technicalities, was to simplify it. And I meant to simplify it for you readers, too, not just for me.

So, over the last few days, I put in place this plan:

• Simplify the site’s appearance. Done.
• Move the site’s hosting from Cloudflare Workers Sites back to Vercel. Done. In my tests over the last half-year, I’ve found that Vercel provides great worldwide performance and the fastest build speeds in the field while requiring no futzing around with GitHub Actions for builds.⁴
• Take the site back to single-binary land with Hugo. Done. (Well, you probably figured that out some time back in this piece, didn’t you?)⁵
• Decide what to do about Tailwind CSS. Still in flux. This is the last battlefield of the war between simplicity and FOMO. If FOMO wins on this count, I keep the ultra-popular Tailwind and the PostCSS it requires — even though the two constitute, yep, buckets of Node.js dependencies. If simplicity wins, the site goes back to SCSS, as in the site’s first year-and-a-half under all three SSGs on which it existed during that period.⁶

At least until I decide that last item, I am maintaining two different themes in the Hugo repo. One is built on Tailwind, and the other on SCSS. (I named them “thoreau” and “thoreauscss,” respectively.) While I continue to consider the choice, I can easily switch back and forth between them with a simple edit to the site’s config file. [Update, 2021-03-01: Decided to go with SCSS, but still have PostCSS for using Autoprefixer.]

Important: Be assured that every compliment I’ve ever paid to Eleventy, Tailwind, and/or PostCSS still applies. For those who don’t have a problem with Node.js dependencies, I continue to give my highest recommendation to these projects, most especially Eleventy. All three are actively and lovingly maintained, and currently are far and away the best of their respective breeds (in Eleventy’s case, that would be JavaScript-based SSGs).

Time to let others run

Just when I thought I was out, they pull me back in.
— Michael Corleone, The Godfather: Part III.

Indeed.

The story I’ve related herein may make it appear that over the last year-and-a-half I have, to paraphrase the Red Queen from Alice in Wonderland, been running as fast as I could to stay in the same place. That’s fair.

In my defense, though, I feel the last nineteen months of experience with multiple SSGs and the Node.js universe have been invaluable. I learned a lot and that always was — and remains — the idea, much more so than indulging FOMO.

Nonetheless, there comes a time to let others do the hard running.

To be sure, I can keep reading about, researching, and testing SSGs and other related geeky stuff in the background; and I will, because I’m a curious fellow (in multiple senses of the word curious). But, when it comes to this site, I believe — hope — that I’ve reached a point where I can make myself stop spending so much time and effort futzing with the house’s paint and foundation.

That way, I can work harder on making its interior more comfortable for those of you who visit.

The welcome mat is always out for you.