What I Like About Eleventy

August 24, 2019

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:

  1. 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.
  2. Performance - Compile times have slowly creeped up. On my computer (WSL on a Core i9), it can take up to 20 seconds to compile on save. This is partially my system, partially because we use a lot of includes in our design system, but probably half of it is Jekyll Assets picking up and running JavaScript through Babel.

This is not heap all the blame on Jekyll Assets (open source is hard!) but after a year of dissatisfaction, we decided to change the infrastructure. In 2019, Autoprefixer and a bundling pipeline for JavaScript is a requirement for us but Jekyll only supports Sass and Coffeescript compilation out of the box.

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 _header.php and _footer.php. Ideally, the parent layout can inherit props (like page.title or 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 if...else and foreach as well as some filters. Filters are little functions that manipulate a string or any array like add, sub, sort, slugify, or 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).

Jekyll Eleventy
15.376s 3.593s

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:

  1. 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 bundler
  2. Being on Node means we can better use npm to manage our JavaScript dependencies. We were doing things the traditional way (folder full o’ JavaScript) because it didn’t make sense to manage two concurrent workflows for Node and Ruby. But now that we’re all Node we can more easily leverage a package.json to maintain, document, manage, bundle, and audit our JavaScript dependencies more efficiently.
  3. We control our asset pipeline. I tried to diagnose and patch Jekyll Assets but I’m not enough of a Rubyist to hack together an asset pipeline alternative. But with JavaScript I’m dangerous enough to roll my own and have quite a few options: npm scripts, gulp, parcel, rollup, or even webpack.
  4. You can use npx @11ty/eleventy to 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.