Blasts from the past

As I noted a few days ago in “Tying up some recent loose ends,” I labor under no illusions that you good folks out there are going to watch this site like a hawk for updates to previously posted content. In similar fashion, I know that only some of what’s gone here before will get viewed at all.

Thus, if a newer visitor is to know about the older content, and particularly if such a visitor doesn’t luck onto the exact combination of magic words that one’s chosen search engine wants to see before providing a link to one of my posts, it behooves me to revisit some of the (I hope) helpful nuggets I’ve put here before.

That’s the purpose of this post.

As my regulars know, I write often about website development in general and static site generators (SSGs) in particular, and that will be obvious as you proceed.

For each item shown, I link to relevant posts, ordered chronologically by their original publication dates. Incidentally, what appears below may in fact have newer and/or additional information not included in any post listed with the item.

An SSG for your site

If you need to pick an SSG for maintaining your personal blog, my suggestion remains what it long has been: a “pick-’em” between Eleventy and Hugo. How can you choose between them? After all, both produce equally fast websites, all other things being equal, so visitors’ perceived performance is also a “pick-’em.” From there, I’d break it down this way:

• If you’re really into JavaScript (or want to be), go with Eleventy. You’ll be much more comfortable there.
• If you want the greatest flexibility in templating, Eleventy is a no-brainer choice.
• If you want maximum speed in development mode, go with the staggeringly fast Hugo. Be prepared to get comfortable with its wonky templating, however.
• If you don’t want to deal with plugins and dependencies, go with Hugo. Eleventy is a combination — albeit an expertly assembled/maintained combination — of Node.js packages, while Hugo is a single binary with “batteries included.”
• If you want to add features of your own choosing, go with Eleventy. This is where the Node.js universe has the advantage if you’re willing to deal with all those added packages. (Hugo isn’t nearly as extensible but, precisely for that reason, also is less brittle.)
• If your site has, or is going to have, a lot of content — I’m talking thousands of pages or more — go with Hugo. Although Eleventy can be used for mammoth sites, Hugo’s sheer power makes them less onerous to manage, especially in dev mode.¹
• If your site is going to have multi-language content, go with Hugo, which has built-in support for that.

What about the oft-mentioned Astro? Although I retain very good feelings about Astro and the outstanding people behind it, I’ve personally found developing in Astro can still be annoyingly slow on a site with more than thirty or forty MDX files. However, if yours is smaller than that and likely to stay that way for a while, you may find the Node.js-based Astro your cup of tea, doubly so if you’re at least somewhat familiar with coding for tools such as Next.js.

As for Gatsby, the only other SSG I’ve ever used to manage this site, you can do so much better. Save yourself the trouble.

(I advise newcomers to this site that the unintentional irony within the first few titles comes from my infamous 2019 “Dance” among various SSGs.)

• “Why I’m staying with Hugo” (2019-07-14).
• “Lessons learned” (2019-07-21).
• “Why I left Hugo for Eleventy” (2019-09-08).
• “Back with Hugo” (2019-09-20).
• “Now I’m a Gatsby geezer” (2019-10-27).
• “Packing up” (2019-12-08).
• “Sorta StranGe (SSG) trip” (2019-12-27).
• “A normal person’s guide to static websites” (2020-09-12).
• “Eleventy and Hugo: comparing and contrasting” (2020-12-28).
• “Simplify, simplify” (2021-02-06).
• “Is Astro ready for your blog?” (2022-04-24).
• “The winds of change” (2022-04-26).
• “Mulling over migration?” (2022-05-07).
• “Cloudflare dev docs and the switch from Gatsby back to Hugo” (2022-05-27).
• “Impressions from HugoConf 2022” (2022-07-11).
• “The ‘staying with Hugo’ post, three years later” (2022-07-14).
• “Really getting started with Hugo” (2022-07-19).
• “Accepting reality about Astro” (2022-10-05).

Jamstack-based website hosting

Getting your SSG-powered site actually on the web is best done through a Jamstack-savvy hosting vendor, where you can automatically build your site on each change you push to your online Git repository. Each such vendor puts your site on a content delivery network (CDN), ensuring your site’s content is “closer” (and thus delivered more quickly) to your visitors, regardless of their locations.

The hosting vendor I’ve used for over a year now, and which I recommend, is Cloudflare Pages, which provides all the advantages of Jamstack-savvy hosting combined with the most extensive CDN in the field, especially given that it’s on the free tier. I’ve also used the free tiers of Netlify, Vercel, Render, and Firebase — as well as a Cloudflare Workers site, the predecessor of Cloudflare Pages.

• “Publish or perish” (2019-04-11).
• “O say can you CI/CD?” (2020-06-28).
• “Goodbye and hello” (2020-07-02) (plus its four sequels, each of which is linked to its successor).
• “A normal person’s guide to static website hosting” (2020-09-26).
• “Ignition sequence start” (2020-09-27).
• “Forward Paas” (2020-10-11).
• “Beta-testing Cloudflare Pages” (2021-01-27).
• “My website and Cloudflare, a year later” (2021-10-22).
• “Gems in the rough #12” (2021-12-26).

Styling your site

Over much if not most of this site’s existence, I’ve styled it with Sass, although I’ve also used (and admired the development behind) the hugely popular Tailwind CSS. There even was a time when I used only more-or-less basic CSS but with the PostCSS preprocessor, but I thought better of it later.

I prefer Sass because it comes with everything I need for styling, so I don’t have to fuss with additional items and their potential breaking changes — somewhat similar to that whole “batteries included” thing with Hugo that I mentioned earlier. However, where Hugo is concerned, using the current version of either Sass or Tailwind CSS can be problematic; so I’ve spent some time explaining how to get around those issues unless/until there are more official solutions.

• “Getting framed” (2018-11-14).
• “Grid-locked no more” (2018-11-28).
• “Two cheers for Tailwind” (2020-01-12).
• “Going solo with Eleventy” (2020-05-09).
• “Tailwind-to-head with Hugo Pipes” (2021-02-02).
• “JIT is a game-changer for Tailwind CSS” (2021-03-19).
• “Tailwind-to-head with Eleventy” (2021-03-20).
• “Speaking up for Sass” (2021-04-03).
• “A zero-JavaScript navigation menu for Tailwind CSS” (2021-09-15).
• “Making Tailwind JIT work with Hugo” (2021-11-01).
• “Should you adopt Tailwind 3?” (2022-01-12).
• “Making Tailwind JIT work with Hugo, the Version 3 edition” (2022-03-06).
• “Using Dart Sass with Hugo: the GitHub Actions edition” (2022-05-17).
• “Cache-busting in Eleventy: a simpler way with Sass” (2022-09-19).

Web fonts

If you choose to use web fonts, don’t use any served by Google Fonts, so as to avoid the tracking code that accompanies them from there. Instead, download their files and serve them from your site.

I also suggest using variable versions of web fonts, where possible, because they provide more styling choices but with smaller files and smaller numbers of files. That’s even truer if you properly subset them to eliminate all but the characters you truly need.

And, hey: there’s absolutely nothing wrong with using the system fonts stack — relying on the fonts built into your visitors’ operating systems and devices — especially in this era when those fonts, and the devices displaying them, do so much better than in the past.

• “A stacked deck” (2018-10-25).
• “Chasing 100: tips for optimizing your website” (2020-07-16).
• “Google Fonts and privacy” (2020-08-08).
• “Good stuff without Google” (2020-08-09).
• “Down with flabby fonts” (2021-08-08).
• “Adding the Libre Franklin variable web font” (2022-10-04).

Static embeds

It can enhance your site if you embed things like YouTube videos and tweets, but be careful: using the providers’ default methods for such embeds will inflict a ton of sneaky tracking code on your visitors. The better way is to embed the content fully statically, providing virtually the same content and appearance but without the tracking.

Note: Due to changes in the status and/or availability of one or more Twitter APIs, perhaps due to the many corporate changes at Twitter itself following its purchase by Elon Musk, I have deprecated several posts, or sections thereof, concerning the fully static embedding of tweets within one’s website. However, all the relevant URLs still work, and each provides a link for viewing its now-deprecated content.

• “Gems in the rough #9” (2021-09-05).
• “Static tweets in Eleventy and Hugo” (2022-02-07).
• “Static tweets in Eleventy and Hugo: Part 2” (2022-02-11).
• “Gems in the rough #14” (2022-02-18).
• “Static tweets in Astro” (2022-04-06).
• “Static Mastodon toots in Hugo” (2022-06-03).
• “Static tweets in Hugo: an update” (2022-06-07).
• “Static tweets in Hugo: a tale of two sources” (2022-08-02).
• “Static tweets in Astro: the two-sources edition” (2022-08-26).
• “Static embeds in Eleventy” (2022-08-27).
• “Static Mastodon toots in Astro” (2022-08-29).
• “Take a load off” (2022-09-04).

What’s wrong with WordPress?

Those website maintainers who are familiar, even comfortable, with the WordPress content management system (CMS) can tend to get annoyed when we SSG users try to pull them over here and away from The Dark Side. Why, they ask, would I ever want to leave WordPress for an SSG?

It all comes down to performance and security.

1. A WordPress site is dynamic — i.e., every visit generates a page on-the-fly from a database — and that makes it slower than a static site, which is just a set of pre-built, ready-to-view static files.
2. The database also makes a WordPress site less secure than an SSG-built site. Bad actors love nothing better than to crack a database that isn’t sufficiently protected (“hardened”), which unfortunately describes many WordPress sites’ databases and the platforms on which they exist.
3. To gain additional features, nearly every WordPress site uses plugins, sometimes a lot of them, and every additional plugin (a.) further slows down the dynamic page-building process and (b.) constitutes another potential security vulnerability, especially since many plugins are poorly coded and/or maintained.

However . . . if one still prefers WordPress just for its CMS capabilities, at least there are ways to make WordPress serve as an SSG².

• “HardyPress: WP + SSG with a twist” (2018-09-15).
• “Blox sux” (2019-01-19).
• “Ec-static” (2019-04-07).
• “Chasing 100: tips for optimizing your website” (2020-07-16).
• “A normal person’s guide to static websites” (2020-09-12).
• “Easy-peasy” (2021-01-03).

Latest commit (4c23918b) for page file:
2023-03-05 at 10:40:50 PM CST.
Page history