This site is now powered by a static site generator called 11ty. It’s awesome! I’ll try to explain some of my favourite things about it and reasons you might prefer it to stalwarts in the SSG arena.

15 years ago, training up on Django, I built a blog. It’s what webdevs did back then. It was really fast compared to WordPress but the editing always fell short, the database design got in the way more than it helped. Dogfooding your software means every problem is yours. I had a glossy coat but the jelly and chunks arrested my writing process.

SSGs are perfect for blogs and brochure websites

Static site generators churn content through templates into a static website that you can just upload to a simple webserver. This is unlike Django or any other dynamic language, where you host a running process and database on an expensive server 24/7 to generate HTML on demand. You’re just serving files, for free.

Most sites don’t need fresh fresh HTML for every request. They don’t change often enough. A blog or a business’ brochure website might get updates anywhere from a couple of times a day to only once or twice a year. With a static site generator, you can make your edits and regenerate the site.

I’ve used a few SSGs professionally: Jekyll, Hugo and Nuxt.

So why ignore all of those and use 11ty?

Jekyll is glacial on Cloudflare’s CI/CD environment; about 3 minutes a build. Hugo is Fast but can be a nightmare to work with when things go wrong. Absolutely user-error, but I’ve wasted days at a time banging my head on Hugo. Both Jekyll and Hugo being non-JS options have their own take on asset management. I’m also a Vue developer so Nuxt is great for me, but force-feeding users a bundle of Vue, Nuxt and routers and whatnot, just for a blog? It’s silly. It does have top-shelf asset management though.

11ty was a perfect balance between Hugo and Nuxt. I get all my favourite frontend tools (PostCSS, PurgeCSS on here) with a generator that isn’t trying to force-feed my users a massive script bundle.

It’s been 3 weeks, 2 days since my initial commit on this site’s repo and since finishing the conversion I’ve written more posts than I did in the previous decade, and I’ve also converted two Jekyll sites over too. Each took about an afternoon. Perfect URL parity, nothing ostensibly different, just a [much] better toolchain.

11ty is Fast Enough™ for developers

While build performance does matter, it only matters to a point. On this seven year old laptop 11ty can pump out 400 pages, the whole website, in well under two seconds:

Copied 403 files / Wrote 539 files in 1.46 seconds (2.7ms each, v1.0.1)

It’s a whole second faster on my desktop. Strangely enough --incremental doesn’t make it any faster.

But really, the only time that matters is that it’s faster than the time it takes me to switch to my browser. Hugo probably is faster but anything less than 2 seconds is Fast Enough™. That’s what I mean. That’ll do pig.

11ty is bloat-free for visitors

This is much more important, and might explain why I’ve had preferential experience with Jekyll and Hugo in the past.

Many Javascript-based SSGs bundle in client code too. Sometimes this makes sense: You might use Next and Nuxt to build component rich SPAs, but for blogging and brochure stuff, an extraneous 100KB of swarf delivers a poor user experience.

11ty is one of the few JS SSGs that doesn’t force script on your users. If you want “pure” HTML, that’s what you’ll get. If you’re economic with your CSS and images, it’s easy to juice the performance stats.

11ty comes with batteries

You don’t have to pick between Markdown and Pug, Liquid or Nunjucks. You get them all, and more. Frontmatter can be in YAML, TOML, HAML, JSON even build-time javascript. So what? So what?! You wouldn’t say that if you’d ever wasted a day trying to work out what the hell a Hugo site was doing because of a typo in a template who’s syntax was so thick and unwelcoming, people build castle walls with it. 11ty is simple.

There’s also a huge pile of community 11ty plugins too.

11ty helps you use your own batteries

If you don’t get on with something in 11ty, you use something else, or rip it out and do your own thing.

This was best demonstrated for me when I wanted to extend the Markdown formatter. My old posts had short-code in to generate Youtube embeds, special floats, etc. Converting this over from Django was easy with a couple of third-party projects, markdown-it and markdown-it-container. Here’s an example of a little explainer short-code I now have:

Adding template-filters for all the bundled template languages is also made really simple:

  eleventyConfig.addFilter("striptags", v => v.replace(/(<([^>]+)>)/gi, ""))

If you’ve ever used opinionated software before, perhaps even your own, you’ll recognise and appreciate that 11ty isn’t just getting out of your way, it’s going out of its way to make your life easy.

Three sites in, what’s not so good?

Pagination is good and frustrating in equal measure. Collections seem like a good idea, filtering them into new collections is easy enough, but actually paginating them can be a bit of a mess. To show a tag page, for example, you actually use pagination to filter the collection. But then you can’t [easily] paginate that data. If I had hundreds of posts in any one tag, this’d be a problem.

There could also be a slightly tighter asset build system. I want PostCSS to know my output HTML (so PurgeCSS can slice down the CSS) but I also want to hash my static filenames to not get stale cache entries, which would change the HTML. I currently do this with a hairy find-and-replace after the build.

A scoped include like Django’s would solve a couple of problems I’ve hacked around:

{% include 'template' with variable=value %}

But these are small complaints. It works well and I’m really happy with it. I’d heartily recommend it to anyone.