Going static with Eleventy

While doing some updates earlier this year, I came to the realisation that having a dynamic site running for this portfolio and blog may just be overkill. I mean, it’s not like I post multiple times a day or still do so many freelance projects that I needed to update the site every other week.

I’d been struggling with justifying to myself all the time I’d been investing into the various side-projects I’m maintaining was worth it. Keeping frameworks up-to-date to ensure there’s no security vulnerabilities, then keeping the underlying PHP version up-to-date to support the new requirements, and then finally having to keep the distro up-to-date as well to support all this new and shiny.

The fact that the newer versions of Laravel required a version of PHP not “natively” supported by the latest stable Debian also played its part. I was just tired of constantly having to upgrade for no discernable benefit.

So, about seven weeks ago I took every weeknight and read up on what other options there were. I looked at Jekyll (based on its use by GitHub Pages), Hugo, Gatsby, and Eleventy. I remembered playing around with Jekyll a few years back when I had a similar idea, but it just didn’t feel right to me. Hugo and Gatsby seemed interesting, but there was just something about Eleventy that caught my interest.

The following weekend I decided to see what I could do in a morning, and by lunchtime I had a basic replica of the Laravel site up-and-running. I took the rest of the afternoon and the Sunday morning to polish it and give it a slight update, and the Sunday afternoon was spent figuring out how to deploy it in lieu of Envoy which I’d been using for the Laravel site.

I wanted to see if I could make use of GitHub Actions, and thanks to appleboy/scp-action, I was off to the races. By the Sunday evening it’d been deployed to my server with some slight tweaks to the nginx config files to remove the PHP parts. End of story.

But, no.

I had another side-project that I’d been wanting to do for a few years. An amalgamation of a journal, funny memes, old calendar entries worth keeping, random photos, and such. A digital junk drawer, so to speak.

Being freshly inspired by this site’s implementation, I got started on it. With everything I wanted to do, I needed to delve a bit deeper seeing as I was going to need to use JSON data files instead of relying on the front matter of Markdown files. This required a few more evenings of reading up before bedtime, and I learned so much more than just about the data. A nice takeaway from that was how to better organise the folder structure. I went with:

|- assets
|  |- _11ty
|     |- filters
|     |- shortcodes
|  |- _data
|  |- _includes
|  |- _layouts
|  |- images
|  |- styles
|  |- tailwind.config.js
|- build
|- content
|- .eleventy.js
|- package.json

This allowed a (mostly) nice clean break between content and supporting files. The one exception being supporting files in the root of content to generate the index page, tag pages, and content pages where only data was available but nothing else happened on a specific date. To move the _data, _includes and _layouts outside of the content folder (as per the default Eleventy behaviour) required just the following simple trick:

module.exports = function(eleventyConfig) {
    return {
        dir: {
            input: "content",
            output: "build",
            // ⚠️ These values are relative to your input directory
            includes: "../assets/_includes",
            layouts: "../assets/_layouts",
            data: "../assets/_data"
        }
    }
}

Another nice thing I found to keep the .eleventy.js config file tidy was to move the shortcodes and filters into their own files and then simply require them with:

eleventyConfig.addFilter("filterName", require("./assets/_11ty/filters/filterName"))

I’ll post a follow-up to delve deeper into how I combined the “real” content files with the collections’ data and also how I handled the situations where there was only data and no “real” content file.

Until then I’ll be busy looking at all my other side-projects to see which of them would be better suited as a static site.