Over the last month so, I’ve been working with Dr. Julian Jones to port some design system projects from Jekyll over to Eleventy, the feral possum of static site generators. Why undertake a whole replatforming initiative? Well, there were two primary issues we were trying to solve:
- Robustness - About a year ago our Autoprefixer quit generating some flexbox prefixes. We filed an issue for Jekyll Assets but we’ve heard nothing back. Even though we don’t officially support IE9/10, getting CSS compat with a browserconfig is a nice to have and would resolve some weird inconsistencies with production.
We’re close to wrapping up this migration and I was asked on Twitter to write about it. So, without further ado, here’s what I like about Eleventy…
Eleventy is Jekyll-like
Eleventy has a similar API to Jekyll. What I mean by this is that it has a few core features of a static-site generator that we require.
- Layout Inheritance
A good static site generator needs a concept of “layouts” which are a step up from
_footer.php. Ideally, the parent layout can inherit props (like
page.bodyClass) from the child page, usually stored in some YAML Front Matter.
- Simple Templating with Filters
I don’t need all of PHP/Ruby/JS in my templates. I prefer templates to be near-logicless but I’ve found that you’ll always need some basics like
foreachas well as some filters. Filters are little functions that manipulate a string or any array like
modulo. Especially in a JAM Stack mindset where you render data from an API, you need a few tools to reformat data on-the-fly in your template.
- JSON Data Folders
One day clients are going to figure out my secret where I steal JSON from their API and put in a
data/folder to use real data building prototypes. It speeds up prototyping and gives you a more realistic representation of what you’re trying to build. I use this feature liberally.
If I have these features then I have most of what I need. One huge convenience is that Eleventy supports Liquid templates as well as a handful other popular templating engines. Eleventy’s flexibility here makes it a good candidate (over other static-site generators) for migrating a design system with dozens and dozens of small partials already written in Liquid.
Eleventy is Fast
Compared to our previous Jekyll build, the initial results are very promising for our main task that compiles pages, compiles Sass, and transpiles our ES6 code (for IE11).
It’s literally 5x faster for me! To say this will have an impact on my speed of development is an understatement. I’m less likely to start another task or drift over to YouTube while waiting for a file to save.
Perf stats like this are highly subjective to my computer and my project, so if Jekyll works for you and still feels fast, that’s great! Please don’t change anything because of this post! I’ve seen huge improvements by moving my personal blog to Jekyll 4 and WSL2 and am seeing sub-second initial compile times and half-second regenerations.
But, at the time of writing, we’re version locked to Jekyll 3.8.6 by Jekyll Assets. In our situation, everyone (on both Mac and Windows) was feeling the drag of compile times. If there’s a Doherty Threshold for static-site generators, I think it’s around three second compile times.
Eleventy is built on Node
There are a few benefits of switching over to a Node-based static site generator:
- You can install Node by downloading a binary from their website for Mac and Windows. It’s hard to quantify how much easier this is to get someone new up and running on a project compared to installing
homebrew, to install
rbenv, to install
ruby, to install
- Being on Node means we can better use
rollup, or even
- You can use
npx @11ty/eleventyto run Eleventy without installing it! This is a niche feature but a good code smell for me. It means we’re using Eleventy purely as a file-processor. To me it’s a subtle nuance between using a tool and being pinned under a dependency.
I still love Ruby, but maintaining one system is much easier than maintaining two.
Tradoffs from switching to Eleventy
This list is short, but I think it’d be fair to discuss some of the tradeoffs we’re making by a platform switch.
On the Cathedral vs. Bazaar spectrum, Eleventy operates more on the bazaar end. By that I mean it doesn’t prescribe much. You want a bunch of filters? Write your own, Eleventy only comes with two. You want multiple layouts? Write a bit of JS to get those registered. Did you remember to setup an
.eleventyignore? Even the Sass and JS pipelines are BYO.
The overhead here isn’t too dramatic, but this may not be in everyone’s comfort zone. Switching from Jekyll can be a big task if you used all of Jekyll’s features. There was quite a bit of manicuring to get us to where the whole project would compile. But for us, if we can save 12 seconds on every save and we get better JS package management out of the deal, we’ll start reaping the return on investment quite quickly.
Should you switch to Eleventy?
If you’re not feeling the slowdown and the speed improvements in Jekyll 4 are working for you, then it’s probably not worth the switch. The best thing I could say is.. Try it!
We’re finding Eleventy to be a good fit for lots of our projects going forward… And pair Eleventy with Netlify and you’ve got quite a nice setup with near-instant branch deploys, serverside A/B testing, serverside analytics, password protection, and can even dip your toes into serverless.