Zach Leatherman

A note from my late Grandmother about Eleventy

2025-08-19T05:00:00Z

Our basement flooded this week, so I’ve been cleaning up the mess. In that process, I found a 22-year-old letter from my grandmother (who passed away Christmas 2023) to my mom that had a little Eleventy naming history that some folks might enjoy.

I first talked about the significance and history of the Eleventy name back in a blog post from 2018 celebrating the project’s first birthday:

I chose it because of a story my grandma Nonnie loved to tell about how I learned to count. Rather than move from ten to eleven like a normal child, I felt it appropriate to use the teen suffix for the numbers eleven and twelve, counting “ten, eleventy-teen, twelvety-teen, thirteen, …”

The discovery of this letter was very surprising to me as I hadn’t reviewed the contents of this box in almost 20 years (long before Eleventy). I’ll include a photo of the letter and of the newspaper clipping of the Dennis the Menace comic she had included below (with some redacted unrelated personal details for brevity).

Dennis the Menace really hit a soft spot with me this week, so I am sending it to share with you. When Zach was about three or four, he was counting for me and after ten he said “leventy teen.” When I said, “But Zach, we don't say 'leventy teen,” I got this reply. “But I do. I do say 'leventy teen.” That has always been one of my favorite memories. So now we know there really is a “leventy teen.” He was right all the time.

Miss you, Nonnie

One weird trick to reduce Eleventy Image Build Times by 60%

2025-08-01T05:00:00Z

This web site does a fair bit of build-time Image Optimization using the HTML Transform method provided by the Eleventy Image plugin. I took a bit of a set-it-and-forget-it approach with the plugin on this site, mostly for my own convenience. My usage looked something like this:

import { eleventyImageTransformPlugin } from "@11ty/eleventy-img";

export default function(eleventyConfig) {
	eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
		failOnError: false,
		formats: ["svg", "avif", "jpeg"],
		svgShortCircuit: true,
	});
};

Eleventy Image includes a fair number of caches and performance optimizations to make this default behavior pretty fast.

It uses a memory cache to de-duplicate multiple requests to optimize the same input image.
It uses an on-request image processing engine to avoid processing images during local development.
It uses a hash for output file name and checks the target file location to avoid reprocessing images.

The biggest drawback with the third method is that when you’re building on a deployment server, these environments start with an empty output folder (and thus, an empty disk cache). What can we do to re-use the disk cache and avoid reprocessing unchanged images on each new deploy?

With just a few lines of configuration code to create an intermediate output folder in a location that is persisted between builds (.cache), I was able to drop my site’s build time from an embarrasing 9:40 down to a respectable 3:56 (for throughput info, the output folder has 7,779 files weighing 492.7 MB).

I think this approach is very reusable and we’ll likely bundle it into a future version of Eleventy Image. Until then, you can use it yourself by adding the following lines of configuration:

+import path from "node:path";
+import fs from "node:fs";
 import { eleventyImageTransformPlugin } from "@11ty/eleventy-img";

 export default function(eleventyConfig) {
 	eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
+		urlPath: "/img/built/",
+		outputDir: ".cache/@11ty/img/",
 		failOnError: false,
 		formats: ["svg", "avif", "jpeg"],
 		svgShortCircuit: true,
 	});

+	eleventyConfig.on("eleventy.after", () => {
+		fs.cpSync(".cache/@11ty/img/", path.join(eleventyConfig.directories.output, "/img/built/"), {
+			recursive: true
+		});
+	});
 };

You could improve the above example by restricting the copy step using the process.env.ELEVENTY_RUN_MODE environment variable.

You may also need to persist .cache on your web host. This behavior is provided for-free if you’re using Vercel or Cloudflare Pages.

Subscribe to github.com/11ty/eleventy-img/issues/285 for future updates.

Never write your own Date Parsing Library

2025-07-23T05:00:00Z

Never write your own date parsing library.

Never. No exceptions.

~~Never have I ever…~~

So… I’ve written my own date parsing library.

Why? Our story begins seven years ago in the year 2018. I made the very sensible choice to adopt luxon as the Date Parsing library for Eleventy. This parsing behavior is used when Eleventy finds a String for the date value in the Data Cascade (though YAML front matter will bypass this behavior when encountering a YAML-compatible date).

This choice was good for Eleventy’s Node.js-only requirements at the time: accurate and not too big (relatively speaking). Eleventy has used luxon since @0.2.12 and has grown with the dependency all the way through @3.7.1. Now that’s what I call a high quality dependency!

As we move Eleventy to run in more JavaScript environments and runtimes (including on the client) we’ve had to take a hard look at our use of Luxon, currently our largest dependency:

4.7 MB of 21.3 MB (22%) of @11ty/eleventy node_modules
229 kB of 806 kB (28%) of @11ty/client (not yet released!) bundle size (unminified)

Given that our use of Luxon is strictly limited to the DateTime.fromISO function for ISO 8601 date parsing (not formatting or display), it would have been nice to enable tree-shaking on the Luxon library to reduce its size in the bundle (though that wouldn’t have helped the node_modules size, I might have settled for that trade-off). Unfortunately, Luxon does not yet support tree-shaking so it’s an all or nothing for the bundle.

The Search Begins

I did the next sensible thing and looked at a few alternatives:

Package	Type	Disk Size	Bundle Size
`luxon@3.7.1`	Dual	`4.59 MB`	`81.6 kB` (min)
`moment@2.30.1`	CJS	`4.35 MB`	`294.9 kB` (min)
`dayjs@1.11.13`	CJS	`670 kB`	`6.9 kB` (min)
`date-fns@4.1.0`	Dual	`22.6 MB`	`77.2 kB` (min)

The next in line to the throne was clearly dayjs, which is small on disk and in bundle size. Unfortunately I found it to be inaccurate: dayjs fails about 80 of the 228 tests in the test suite I’m using moving forward.

As an aside, this search has made me tempted to ask: do we need to keep Dual publishing packages? I prefer ESM over CJS but maybe just pick one?

Breaking Changes

Most date parsing woes (in my opinion) come from ambiguity: from supporting too many formats or attempting maximum flexibility in parsing. And guess what: ISO 8601 is a big ’ol standard with a lot of subformats. There is a maintenance freedom and simplicity in strict parsing requirements (don’t let XHTML hear me say that).

Consider "200". Is this the year 200? Is this the 200th day of the current year? Surprise, in ISO 8601 it’s neither — it’s a decade, spanning from the year 2000 to the year 2010. And "20" is the century from the year 2000 to the year 2100.

Moving forward, we’re tightening up the default date parsing in Eleventy (this is configurable — keep using Luxon if you want!).

Luckily we have a north star date format: RFC 9557, billed as “an extension to the ISO 8601 / RFC 3339” formats and already in use by the upcoming Temporal web standard APIs for date and time parsing coming to a JavaScript runtime near you.

There are a few notable differences:

Format	ISO 8601	`Date.parse`*	`luxon`	RFC 9557
`YYYY`
`YYYY-MM`
`YYYY-MM-DD`
`±YYYYYY-MM-DD`
Optional `-` delimiters in dates
`YYYY-MM-DDTHH`
`YYYY-MM-DD HH` (space delimiter)
`YYYY-MM-DDtHH` (lowercase delimiter)
`YYYY-MM-DDTHH:II`
`YYYY-MM-DDTHH:II:SS`
Optional `:` delimiters in time
`YYYY-MM-DDTHH:II:SS.SSS`
`YYYY-MM-DDTHH:II:SS,SSS`
Microseconds (6 digit precision)
Nanoseconds (9 digit precision)
`YYYY-MM-DDTHH.H` Fractional hours
`YYYY-MM-DDTHH:II.I` Fractional minutes
`YYYY-W01` ISO Week Date
`YYYY-DDD` Year Day
`HH:II`
`YYYY-MM-DDTHH:II:SSZ`
`YYYY-MM-DDTHH:II:SS±00`
`YYYY-MM-DDTHH:II:SS±00:00`
`YYYY-MM-DDTHH:II:SS±0000`

: Unsupported
: Inaccurate parsing
Face looking surprised: Surprising (to me)

* Note that Date.parse results may be browser/runtime dependent. The results above were generated from Node.js.

A new challenger appears

It is with a little trepidation that I have shipped @11ty/parse-date-strings, a new RFC 9557 compatible date parsing library that Eleventy will use moving forward.

The support table of this library matches the RFC 9557 column documented above. It’s focused on parsing only and our full test suite compares outputs with both the upcoming Temporal API and existing Luxon output.

While there are a few breaking changes when compared with Luxon output (noted above), this swap will ultimately prepare us for native Temporal support without breaking changes later!

Package	Type	Disk Size	Bundle Size
`@11ty/parse-date-strings@2.0.4`	ESM	`6.69 kB`	`2.3 kB` (min)

This library saves ~230 kB in the upcoming @11ty/client bundle. It should also allow @11ty/eleventy node_modules install weight to drop from 21.3 MB to 16.6 MB. (Some folks might remember when @11ty/eleventy@1 weighed in at 155 MB!)

Late Additions

For posterity, here are a few other alternative date libraries / Temporal polyfills that I think are worth mentioning (and might help you in different ways on your own date parsing journey):

Package	Type	Disk Size	Bundle Size
`@js-temporal/polyfill@0.3.0`	Dual	`2.98 MB`	`186.5 kB` (min)
`temporal-polyfill@0.3.0`	Dual	`551 kB`	`56.3 kB` (min)
`@formkit/tempo@0.1.2`	Dual	`501 kB`	`17.3 kB` (min)

How to import() a JavaScript String

2025-06-09T05:00:00Z

You can use arbitrary JavaScript in front matter in Eleventy project files (via the js type).

Historically Eleventy has made use of the node-retrieve-globals package to accomplish this, which was a nightmarish conglomeration of a few different Node.js approaches (each with different advantages and drawbacks).

Related research: Dynamic Script Evaluation in JavaScript

The biggest drawbacks to node-retrieve-globals include:

CommonJS code only (even in a require(esm) world). While dynamic import() works, import and export do not. Top level await is emulated typically by wrapping your code with an async function wrapper.
It uses Node.js only approaches not viable as Eleventy works to deliver a library that is browser-friendly.

Regardless, this abomination was a necessary evil due to the experimental status of Node.js’ vm.Module (since Node v12, ~2019), the ESM-friendly partner to CommonJS-compatible vm.Script. I’d still love to see vm.Module achieve a level of stability, but I digress.

New Best Friend is `import()`

Moving forward, I’ve been having success from a much lighter approach using import(), described in Evaluating JavaScript code via import() by Dr. Axel Rauschmayer. It looks something like this:

let code = `export default function() {}`;
let u = `data:text/javascript;charset=utf-8,${encodeURIComponent(code)}`;
let mod = await import(u);

Newer runtimes with Blob support might look like this (example from David Bushell):

let code = `export default function() {}`;
let blob = new Blob([code], {type: "text/javascript"});
let u = URL.createObjectURL(blob);
let mod = await import(u);
URL.revokeObjectURL(u);

Limitations

Importing a Blob of code does not work in Node.js (as of v24), despite Node having support for Blob in v18 and newer.

Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. Received protocol 'blob:'
import.meta.url just points to the parent data: or blob:, which isn’t super helpful in script.
No import of relative references, even if you’ve mapped it to a full path via an Import Map.
- e.g. import './relative.js'
  
  TypeError: Failed to resolve module specifier ./relative.js: Invalid relative url or base scheme isn't hierarchical.
No import of bare references. These can be remapped via Import Maps.
- e.g. import 'barename'
  
  TypeError: Failed to resolve module specifier "barename". Relative references must start with either "/", "./", or "../".

Though interestingly, Node.js will let you import builtins e.g. import 'node:fs'.

Enter `import-module-string`

I’ve worked around the above limitations and packaged this code up into import-module-string, a package that could be described as a super lightweight runtime-independent (server or client) JavaScript bundler.

I was able to repurpose a package I created in June 2022 to help here: esm-import-transformer recursively preprocesses and transform imports to remap them to Blob URLs (falling back to data: when a feature test determines Blob doesn’t work).

import { importFromString } from "import-module-string";

await importFromString(`import num from "./relative.js";
export const c = num;`);

Where relative.js contains export default 3;, the above code becomes (example from Node.js):

await importFromString(`import num from "data:text/javascript;charset=utf-8,export%20default%203%3B";
export const c = num;`);

Which returns:

{ c: 3 }

This transformation happens recursively for all imports (even imports in imports) with very little ceremony.

When you’ve added a <script type="importmap"> Import Map to your HTML, the script will use import.meta.resolve to use the Import Map when resolving module targets.

Even more features

A few more features for this new package:

Extremely limited dependency footprint, only 3 dependencies total: acorn, acorn-walk, and esm-import-transformer.
Multi-runtime: tested with Node (18+), some limited testing in Deno, Chromium, Firefox, and WebKit.
- This was my first time using Vitest and it worked pretty well! I only hit one snag trying to test import.meta.resolve.
Supports top-level async/await (as expected in ES modules)
If you use export, the package uses your exports to determine what it returns. If there is no export in play, it implicitly exports all globals (via var, let, const, function, Array or Object destructuring assignment, import specifiers, etc), emulating the behavior in node-retrieve-globals. You can disable implicit exports using implicitExports: false.
Emulates import.meta.url when the filePath option is supplied
addRequire option adds support for require() (this feature is exclusive to server runtimes)
Supports a data object to pass in your own global variables to the script. These must be JSON.stringify friendly, though this restriction could be relaxed with more serialization options later.
When running in-browser, each script is subject to URL content size maximums: Chrome 512MB, Safari 2048MB, Firefox 512MB, Firefox prior to v137 32MB.

As always with dynamic script execution, do not use this mechanism to run code that is untrusted (especially when running in-browser on a domain with privileged access to secure information like authentication tokens). Make sure you sandbox appropriately!

line-numbers Web Component

2025-06-05T05:00:00Z

<line-numbers> is a web component to add line numbers alongside <pre> or <textarea> elements.

Install:

npm install @zachleat/line-numbers

Features

<pre> supported
<textarea> supported (even when adding or removing lines)
CSS overflow supported (with obtrusive/visible or nonobtrusive scrollbars)
Numbers are excluded from content flow (not selectable, important for copy paste components!)
Use any CSS counter style via custom property --uln-number-type
Change the starting index for counter via (<line-numbers start="999">)
Numbers are unobtrusive by default to reduce layout shift (opt-in to obtrusive behavior via <line-numbers obtrusive>)

Limitations

Trying to keep this one as simple as possible, so please note the following:

Line wrapping is not supported (white-space: pre or white-space: nowrap only, and this is enforced by the component)
Elements using contenteditable are not supported

Check the speedometer on the brand new Blog Awesome (now with 11ty)

2025-03-28T05:00:00Z

Video: 11ty Meetup: Blog Awesome from WordPress to Eleventy

11ty Meetup: Blog Awesome from WordPress to Eleventy

2025-03-20T05:00:00Z

Watch on YouTube: 11ty Meetup: Blog Awesome from WordPress to Eleventy

Event page on 11tymeetup.dev

Extract Colors from an Image for CSS Themes

2025-02-27T06:00:00Z

Working through the migration of Blog Awesome from WordPress to Eleventy, I encountered an interesting problem: each blog post was seeded with a featured image at the top, though the image did not cover the entirety of the header.

This required a manual process (a WordPress custom field) to specify a theme color to match the background of the image. We can do better!

Using a similar layout structure, this what the new design looks like (with a bit better automatic dark/light mode contrast on the flag and text color, too):

To accomplish this automation, I turned to a lovely zero-dependency package called extract-colors from namide.com.

In all of the eligible blog posts tested, the last color returned in the result from the extract-colors package always matched the background color of the image being sampled.

extract-colors recommends the use of another package (get-pixels) to extract pixel data from images but it was no longer maintained so I forked, updated, and released a Node.js only version of the package to fix some upstream issues.

New `@11ty/image-color` Package

I wired this up with a memoization layer, a disk cache, a concurrency queue, and integrated it with existing overlapping functionality provided by Eleventy Fetch and Image utilities for build performance (as well as adding Color.js for some color filtering) and packaged this all up for anyone to use at @11ty/image-color:

To get colors from a local or remote Image in my Eleventy project, I added the following configuration code to my project’s eleventy.config.js file:

import { getImageColors } from "@11ty/image-color";

export default async function(eleventyConfig) {
	eleventyConfig.addFilter("getImageColors", async (imageSrc) => {
		return getImageColors(imageSrc);
	});
}

The above Blog Awesome example above made good use of the getImageColors filter in a Nunjucks template:

{%- set lastColor = media.featuredImage | getImageColors | last %}
{% if lastColor %}
	<style>
	header {
		background-color: {{ lastColor.background }};
		color: {{ lastColor.foreground }};
	}
	</style>
{% endif %}
<header>…</header>

Screenshot Borders

For extra funsies I also made use of this functionality on 11ty.dev (now live on the site) to provide an extra accent border color on screenshot images:

This example works a little differently: it samples colors from the favicon images of each site as an easy way to guess the site’s theme colors.

This package doesn’t take a hard stance on the validity of colors but I did make use of additional filtering to select a nice border color from the list of colors available in each favicon, with the code looking something like this (again, eleventy.config.js Configuration code):

import { getImageColors } from "@11ty/image-color";

export default async function(eleventyConfig) {
	eleventyConfig.addShortcode("getColorsForUrl", async (url) => {
		let avatarUrl = `https://v1.indieweb-avatar.11ty.dev/${encodeURIComponent(url)}/`;

		return getImageColors(avatarUrl).then(colors => {
			// Note the map to colorjs props here
			return colors.map(c => c.colorjs).filter(c => {
				// Not too dark, not too light
				return c.oklch.l > .4 && c.oklch.l <= .95;
			}).sort((a, b) => {
				return (b.oklch.l + b.oklch.c) - (a.oklch.l + a.oklch.c);
			});
		})
	});
};

…which subsequently wound up in a WebC template a little like this:

<script webc:setup>
async function getPrimaryColorStyle(url) {
	let colors = await getColorsForUrl(url);
	if(colors.length > 0) {
		return `--card-border-color: ${colors[0].toString({format: "hex"})}`;
	}
}
</script>
<a :href="url" class="card" :style="getPrimaryColorStyle(url)">…</a>

More Open Source

This Blog Awesome migration project (launching soon!) has yielded a few more useful open source utilities to the Eleventy ecosystem, which I encourage you to try out!

@11ty/image-color (you already read about this here)
@11ty/import (import WordPress posts as Markdown files)
@11ty/font-awesome (use zero-JavaScript SVG icons)

?nodefine — a pattern to skip Custom Element definitions

2025-02-14T06:00:00Z

The following code is a minimum viable custom element:

class Nimble extends HTMLElement {}

customElements.define("nim-ble", Nimble);

The define call is typically packaged up in the component code (for ease of use) and not in your application code. I typically adapt this into a static function like so:

class Nimble extends HTMLElement {
  static define(tagName) {
    customElements.define(tagName || "nim-ble", this);
  }
}

Nimble.define();

On first glance, this might not offer much benefit, but depending on the platform features I’m using I may also include a Cut-the-Mustard style feature test in there:

class Nimble extends HTMLElement {
  static define(tagName) {
		// Baseline 2020: Chrome 71 Safari 12.1 Firefox 65
		// (extended browser support on top of ESM and Custom Elements)
		if(typeof globalThis !== "undefined") {
			customElements.define(tagName || "nim-ble", this);
		}
  }
}

Nimble.define();

Automatic Definition

The biggest drawback I’m struggling with in these patterns is how to allow folks to opt-out of the customElements.define call when they import or bundle the script. Perhaps they might want to use a different tag name (you can only define a class once in the registry), or run some additional advanced configuration before definition.

Here’s how you would typically import the script code (or import "./nimble.js" works too):

<!-- <nim-ble> is defined for you -->
<script type="module" src="nimble.js"></script>

Here’s a new idea I’m experimenting with to allow opt-out of define() by adding a ?nodefine query parameter to the script URL:

<!-- <nim-ble> is *not* defined for you -->
<script type="module" src="nimble.js?nodefine"></script>
<script type="module">
Nimble.define("some-other-name");
</script>

And then in your component code you’ll check for ?nodefine before auto defining the custom element:

class Nimble extends HTMLElement {
  static define(tagName) {
    customElements.define(tagName || "nim-ble", this);
  }
}

// This line is the magic:
if(!(new URL(import.meta.url)).searchParams.has("nodefine")) {
  Nimble.define();
}

window.Nimble = Nimble;
export { Nimble };

This pattern works with import too:

<script type="module">
// <nim-ble> is *not* defined for you
import { Nimble } from "./nimble.js?nodefine";

Nimble.define("some-other-name");

// Or directly:
customElements.define("nim-ble", Nimble);
</script>

This would also work on any Custom Element code adopting this pattern nestled inside a larger bundle:

<script type="module" src="bundle-398720.js?nodefine"></script>

What do y’all think?

Community Addendums

Updated February 14, 2025 I somehow missed these excellent links which cover similar ground:

Blog Questions Challenge 2025

2025-02-01T06:00:00Z

I was tagged to answer these questions by Anders Thoresson as part of the larger Blog Questions Challenge originally started by ava.

I’ll pass the baton (and a very optional tag to) to Lynn Fisher, Ryan Mulligan, and Sara Joy!

Here are some friends that have already participated:

Ethan Marcotte
Bob Monsour
Maybe you? (If you want me to link to your post, send me a DM)

Why did you start blogging?

I originally started blogging on WordPress during the original era of Blogs, circa 2007. Blogging was a thing often mentioned in popular media — everyone had a blog and was writing on their own space, Google was invested in driving traffic to blogs (via search and a quaint little product known as Google Reader). It was a really great time for independent folks to get started and invest in a platform that would pay off both in the short and long-term.

I also am staunchly of the belief that people should share what they know — it doesn’t have to be something that is novel or exclusive or even new. Share what you know and we all benefit from it.

Unfortunately I also vividly remember a vibe shift when Twitter originally started to get popular and Google Reader was shuttered to make way for Google+. Search feels as though it has been (mostly) conquered by bad actors and social media platforms. A similar shift seems to be happening with how information is consumed via Large Language Models (for the worse).

What platform are you using to manage your blog and why?

I created the Eleventy project to help others create and easily manage content web sites (like blogs), and that’s what I’m using for this site (since 2018). You can read about the early origins of Eleventy on Eleventy, a new Static Site Generator.

Have you blogged on other platforms before?

I do maintain a little table of platform history on my about page. I moved from WordPress to Jekyll in 2013 after going through some dark times with WordPress security vulnerabilities and database scaling issues. Updates needed to be applied on WordPress at approximately the same cadence as early Microsoft Windows and it became cumbersome to manage. I did have plenty of experience with PHP and MySQL at the time but didn’t feel as though that work was worth it for what I was getting out of it.

How do you write your posts?

I write my blog posts in my text editor on my computer (currently VS Code). I don’t write posts on my phone, though I do capture ideas in the Apple Notes app for later iteration. I then commit the posts to the git repository (currently on GitHub) and the site is built on Netlify.

When do you feel most inspired to write?

When I’ve built something new, learned something new, or read something new. I love doing deep dives on new topics but those can be very time consuming to write.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I usually publish immediately and then iterate for a day or two before I share it on socials. If you’re subscribed to my feed you’ll see some of those iterations happen in your reader as I obsess over grammar and copy. This step can only happen after publishing (as issues of this nature are usually invisible to me before publishing).

What's your favorite post on your blog?

The most successful blog post I’ve ever done is A Comprehensive Guide to Font Loading Strategies but it definitely isn’t my favorite.

The first one that jumped out at me was this 2017 blog post about anti-aliasing fonts (also known as font smoothing) titled Laissez-faire Font Smoothing and Anti-aliasing. I learned a lot writing that one and it was a lot of fun.

Any future plans for your blog?

Where do I see my blog in 5 years? Hopefully continuing my current speed of ~30 posts per year and going strong — and still on Eleventy, too .

Zach Leatherman

A note from my late Grandmother about Eleventy

One weird trick to reduce Eleventy Image Build Times by 60%

Never write your own Date Parsing Library

The Search Begins

Breaking Changes

A new challenger appears

Late Additions

How to import() a JavaScript String

New Best Friend is import()

Limitations

Enter import-module-string

Even more features

line-numbers Web Component

Features

Limitations

Check the speedometer on the brand new Blog Awesome (now with 11ty)

Related

11ty Meetup: Blog Awesome from WordPress to Eleventy

Extract Colors from an Image for CSS Themes

New @11ty/image-color Package

Screenshot Borders

More Open Source

?nodefine — a pattern to skip Custom Element definitions

Automatic Definition

Community Addendums

Blog Questions Challenge 2025

Why did you start blogging?

What platform are you using to manage your blog and why?

Have you blogged on other platforms before?

How do you write your posts?

When do you feel most inspired to write?

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

What's your favorite post on your blog?

Any future plans for your blog?

New Best Friend is `import()`

Enter `import-module-string`

New `@11ty/image-color` Package