Thinking out loud about static site generators
4 years on from the last redesign of this website, I’ve inevitably reached the point where I want to revisit earlier choices regarding its design, structure and management.
In an effort to document my decisions and sound out ideas, I’m planning to write a few posts about the changes I’m considering. To kick off, I want to talk about why I’ve chosen a different static site generator.
This site has always been statically generated.
For many years my platform of choice was Movable Type. Conceived during the earliest days of blogging, Movable Type was written in Perl, used an XML-like template language and stored its content in a MySQL database. I was using this to statically generate PHP pages so I could use shared template partials, compile LESS stylesheets and do a small amount of dynamic rendering. In short, a grab bag of languages built upon what had become a languishing platform.
When it came to redesigning the site in 2015, the simplicity of Jekyll was appealing.
Rather than rely on a database, Jekyll uses the concept of ‘flat files’; content saved in Markdown files with metadata prepended using YAML-formatted ‘front matter’. Jekyll parses these files before populating Liquid templates with their content to generate the desired HTML.
Like Movable Type, Jekyll is opinionated software with its technology choices influenced by the tastes of the day. Yet the central concept proved sound, with the flat-file model forming the basis of many subsequent static site generators.
I liked Jekyll, but it had one unfortunate downside: the time it took to build my website. This required countless design compromises and became more of an issue as I published more frequently.
Turning it up to Eleventy
Unlike Movable Type, Jekyll or many of its contemporaries, Eleventy isn’t as opinionated; you can choose from a range of template languages and use multiple data formats.
Such is the power and extensibility afforded by Eleventy, I have vastly expanded the remit of this site. With its ability to use remote data sources, I publish events I’ve attended by fetching and parsing an iCal calendar and add metadata to cinema visits by querying The Open Movie Database API.
Looking to Lume
While Eleventy helped me clarify my needs, I’ve found a project better aligned with my ideas about how a static site generator should work.
That project is Lume.
Like Jekyll, Lume uses flat files to store content. Like Eleventy, it supports different template engines and can generate pages from different data sources.
Unlike Eleventy, its API is clearer and easier to work with. Whereas generating pages from data in Eleventy feels like a hack, Lume takes a more holistic approach. With smart plugins that enable searching and paginating content, paginating pages that they themselves may require pagination is a snip.
However, venture off the beaten track and you may find yourself unable to achieve certain tasks. Deno supports using packages from NPM, but that isn’t always helpful. For example, I’d like to use Lightning CSS to pre-process CSS yet I can’t use it to also bundle files because reasons.
Eleventy and Node.js are like grand old ships. They use mature and proven technologies yet are weighed down by the barnacles of backwards compatibility. Lume and Deno are beautiful solar-powered yachts, their sleek hulls full of promise – just be careful you don’t get lost at sea.
I expect to live with the fifth version of this website for the next half-decade, so hopefully placing bets on these future-facing platforms will pay off. Yet as every seafarer will tell you, at the edge of the map, there be dragons.