As the founder and principal developer of Daedalus Dreams he stays pretty busy!
Well, it was finally time. When it becomes easier to rebuild your entire site than to update the code on the old site, than by jove you build an entirely new site!
Fortunately due to some of the projects that I've been working on lately what tool to use was an easy choice at least.
Eleventy
Eleventy, or 11ty, is a static site generator. It's written in JavaScript and is built on top of Node.js. It's fast, flexible, and it's easy to use. It's also not a framework, it's a tool. It doesn't try to do everything for you, it just does what you tell it to do.
I'm not sure if it's experience, age, grumpiness, or something deeper and more true, but I've been finding that I appreciate the less-magic approach to things. I want to know what's going on, and I want to be able to understand why things are happening the way they are. 11ty has been scratching that itch very nicely.
Static
Static sites mean that sites are easy to deploy, easy to update, and easy to move around. They're also fast, and secure. Given that our simple marketing website isn't going to have a lot of fancy feature, it was an obvious choice.
There are a lot of static site generators to choose from though. In the past I've used Nanoc extensively, but was finding some of the things I wanted it to do to be a little bit of an uphill battle. Opinionated frameworks are good in a lot of cases, and it's usually possible to break out of their specific way of doing things, but sometimes you just want to do things your way. (Also I don't work as much in the Ruby ecosystem as I used to, so keeping up on the dependencies and version updates and everything is a bit more of a bump in my workflow.)
Extensible
11ty lets you use Nunjucks, Handlebars, Mustache, Liquid, or WebC, or pretty much any templating engine you want. It lets you use Markdown, or HTML, HAML or whatever you want for your content. It lets you use whatever you want for your data. It lets you use whatever you want for your build process.
Seeing a theme here?
One of the things I really wanted to be able to do was mix templating languages in order to use the right tool for the right job. In this blog post my source file is Markdown, because it's just a simple text-based post. But I definitely have a few posts in mind that are going to involve some charts and graphs and very specific code requirements. So I can just write that specific post in Nunjucks or raw HTML or whatever suits the need best. That's a huge selling point.
Fast & low-dependency build process
One of the problems I've run into in the past is ease of compiling the site. You want a nice fast build process for development, but you also need something where you can set up and tear down a build server easily if you're going to use automated build and deployment. Not having to pull in specific Ruby versions, or fight with Webpack updates means a build process that's reliable and reproducible. Write blogpost, commit it to git repo, and within minutes the site is updated.
So far 11ty and Node.js have been excellent for this, and the numbers that 11ty shows for build times are pretty amazing, even on sites far far bigger than this one will ever be, so there's plenty of headroom.
Downsides
So, it can't all be sunshine and roses right? Well, since 11ty is more of a screwdriver than an all-in-one 3d-printing, laser-cutting multi-purpose robot, sometimes you have to create a few things yourself.
And what I've found is that this isn't really a downside at all (tricked you!), because now you know exactly how your code is going to behave. "Does the getURL filter work the way I think it does?" Well, I wrote it, so yes.
The only real hurdle I had setting up this particular site was with the Eleventy-Image library, since I wanted to do some image cropping and it just doesn't support that yet. Also it requires an OS dependency (openslide) that wasn't well documented and I had to do some digging to figure out.
One "downside" may be that I end up developing some sort of standard library of functions to use across multiple 11ty sites to make it easier to keep everything up to date and reduce code duplication. I haven't quite figured out how I'll do that yet, but I can already see that I'll probably want to look into it.
What's the new site for?
So why a new site? Well, I've been working on a few projects lately that I wanted to be able to write about. I've also started using some new elements in my tech stack, and it makes it a lot easier to work on the new site when it's using the same tooling you're using to work on customer projects.
Never hurts to modernize either, get that fresh new-site smell back in the air. As time goes on I may try and port over some of the older relevant content that I've written on other sites, so there may be a few items that show up in the archive, but for the most part this is a fresh start.
So stay tuned! I've got a couple of ideas that've been banging around that I'm excited to be writing about soon!
