Ben White — Blog

Getting through the backlog

2026-06-23T00:00:00Z

I have a one-game policy, mainly because I'm old and have a family and bills and taxes. So I basically just play The Finals every night. You'd think I'd be pretty good at The Finals by now!

You'd think.

My one-game policy is like any good policy, it's a rough guideline. Here are the games I've been breaking my rule for lately.

Arc Raiders

Arc Raiders was my overtime for a while. Everyone goes to sleep, it's Arc Raiders time, baby. Playing this game is to accept its stratospheric highs and the deepest, darkest lows.

I like to think I'm pragmatic and principled, but Arc Raiders made me question that self truth. I see myself as a friendly raider. Sure, I'm looting for me, but also for you. We're in this together buddy! But after getting shot in the back a few times, suddenly I'm heading topside for blood. Huh, turns out I'm not as principled as I thought.

The game feels different these days, what with all the racists, sociopaths and cheaters. Time for another game to fill the void.

Clair Obscur: Expedition 33

I'm pretty sure Clair Obscur: Expedition 33 won every "Game of the year" award when it came out ^{[citation needed]}. All I knew going in was: "cool game by small French team".

Within the first few minutes I was like: "Why yes, this is absolutely the most French game I've ever played" and switched to French voice acting, for the complete experience.

When the first combat tutorial popped up, I closed my eyes and sighed. Turn based? Thanks. I hate it. But I persevered, and boy did that pay off.

Clair Obscur: Expedition 33 is a complex, layered, superbly written and beautifully realised story about grief.

The voice acting and writing is just [chef's kiss]. The combat ended up being... really fun!?? After about 40 hours I had finished the main story and the relationship missions. Even though it felt like the game had a lot more to give, I was ready to move on.

Mixtape

I don't really pay close attention to the discourse, but from what I could tell, Mixtape released to widespread critical acclaim, followed by a somewhat predictable backlash from the "Gamers".

Knowledge of backlash was nestled in my mind for my play through. I was sure I'd be able to spot the moment that the "Gamers" didn't like. As the credits rolled, I was like, what the hell? Why are people mad about this game? I went to sleep, and the next day I listened to the Mixtape soundtrack (it's great). Turns out I'm not that interested in what the "Gamers" are angry about. I don't have space in my life for that nonsense.

Was the game life changing? Not really! The main character is annoying and pretentious, like, uh, I was? When I was a teenager? The friend group dynamic looks pretty straightforward on the surface, but body language shows it isn't. And I really like how sometimes, the game isn't interested in going into any of that (sorry Slater).

At some point, you end up drunk in a Blockbuster. The mission: pick out a few movies and get back to the car. At this point I was still playing the game like how I've been trained. Get task, do task, get reward. But as I'm stumbling through the store I bump into a shelf and tapes go flying. Finally! It only took half the bloody game, but finally, I got it. Yes! You can carefully walk in, pick the videos and move onto the next scene, but you'd be missing the entire point. You are a drunk teenager in a video store. The point is chaos! Teenage angst and confusion, rage and joy: The Video Game. After this, I started to really appreciate Mixtape a lot. I loved my handful of hours with it.

So my backlog is a little smaller, my heart a little more full.

On to Pragmata!

First principles

2025-12-03T00:00:00Z

In a meeting room in 2016, my ears perked up. A much smarter person than me had taken a moment to reflect and said, “Let’s bring this back to first principles”. I nodded like I knew what that meant. I mean, I had a general idea... but I didn't realise the magical power that incantation holds.

Many times since, I’ve seen those words duck and weave the strongest egos, opinions, and personalities. I could enter rooms with wildly complex problems, each with endless, conflicting potential solutions, and somehow leave with everyone pointed in the same direction, nodding like Robert Redford.

Recently, I’ve been trying to get my head around what part of our system should do the heavy lifting for any given new feature. As we added new capabilities to our stack, paths that were previously clear cut became murky. I wanted a framework that would help me burn off the fog and help me make choices that were simple to reason and explain. Maybe first principles would help?

Capital Brief is built with 11ty (a static site generator), has access to compute at the edge, and sprinkles of AlpineJS and HTMX in the client. So when it comes to building a new widget, we have plenty of options.

Let’s come up with some first principles:

Do hard work early.
Only compute when absolutely necessary.
Keep the client thin.

Now, let those first principles guide the thinking for some potential website changes.

We need to add a new menu item and related paginated index of stories.

Let’s generate the menu and index at build time and ship them as plain HTML (hard work early). This adds some compute to the build but avoids adding runtime logic (keep the client thin).

We need to check the user’s JWT token and serve different pages to different users.

Let’s validate the JWT and determine the user’s access level at the edge (keep the client thin), then fetch and serve a pre-built page variant (hard work early).

We need to add cachebusting to our CSS and JS file paths.

Let’s generate hashed asset filenames at build (hard work early), store a simple mapping, and let a lightweight edge worker rewrite CSS/JS URLs on the fly so the HTML doesn’t need to be rebuilt for every change (reduce compute).

We need our ad placements to update immediately after changes in the CMS.

Let’s serve static pages with empty ad slots (reduce compute) and use a tiny API/HTMX endpoint that reads the latest pre-built ad config (hard work early) to fill those slots.

Through the lens of first principles, the endless possible solutions for each problem narrow immediately. There’s less ambiguity. We find our path faster, and what we build will more likely align with patterns we’ve already made.

Neat!

Migrating an 11ty site from Cloudflare Pages to Workers

2025-08-04T00:00:00Z

If you're reading this, I'm guessing you've got an 11ty site live on Cloudflare Pages somewhere, and you've probably come across one of the many Cloudflare messages and prompts asking you nicely to move off Pages and over to Workers. It's a bummer, because Cloudflare Pages is a really great product!

If you've used GitHub Pages or Netlify, Cloudflare Pages is easy to pick up. But diving into the Worker docs (and even the Migration docs), they can seem pretty complicated, because, well... they are. For now, let's try and skip past all the complex stuff and just get a Worker to serve our 11ty build.

I'm gonna start with some assumptions:

You have a working 11ty site, which is currently running on Cloudflare Pages
You can build your 11ty site on your own machine
We're skipping multiple environments, secrets and environment variables for now, and just spinning up on local and prod (you can have as many environments as you want, but let's keep it simple for now)
We're going to set things up with commands in a terminal (this is not strictly required, you can set up Workers via the UI, but do note that changes in the UI will be lost the next time you deploy via terminal and vice versa -- best to choose your preferred method of working and stick with that)
We're going to focus on just the site HTML for now, Cloudflare Pages functions or middleware can come later

Let's get into it!

1. Install `wrangler` and login

wrangler is the tool for managing your Worker (both for local development, and deploying to production). The docs recommend installing wrangler as a project dependency via npm i -D wrangler@latest. That's generally good advice, but if you prefer managing things via brew, or want to install it globally, you can absolutely just do that.

Once installed, run npx wrangler login, which will open a browser window asking you to sign in to Cloudflare and authorise wrangler.

2. Configure your Worker

In your project root (probably where your 11ty config lives), add a new wrangler.jsonc file (wrangler.toml is also valid, but JSONC seems like the recommended path these days).

You might already have this file if you deployed your Pages project via code. If so, make sure to remove pages_build_output_dir.

Below is an example for my site, you can fill in the blanks.

{
  "name": "website-benwhite",
  "compatibility_date": "2025-05-05",
  "assets": {
    "directory": "_site",
    "not_found_handling": "404-page",
  },
  "routes": [{ "pattern": "benwhite.com.au", "custom_domain": true }],
}

name: This will be the name of the Worker in the Cloudflare UI, which is only public if you choose to use the {worker-name}.workers.dev URL for anything
assets.directory: You only need to update this if you've set 11ty up to build somewhere else, _site is the default 11ty build path
assets.not_found_handling: This will direct users to the 404.html file in your _site directory. If you don't have a 404 file in your project, or would like to handle 404s differently, have a browse through the routing behaviour docs. There is also a neat diagram on how the worker makes routing choices here.
routes[0].pattern: Make sure you add the www. to your own domain, if that's how your site is currently set up!

The assets config is basically the most important bit, and tells the Worker where to find all the files for your site build. The Static Assets docs have a bunch more detail.

Defining the route in code is just a neat way to reduce the clicks needed in connecting your DNS to the Worker. But as mentioned above, if you want to handle the routes via the UI instead, you can just remove that line.

By not defining a main script file AND setting up assets, we're letting Cloudflare know we want to create an "assets-only Worker". If you want to change this later to move over your Cloudflare Pages Functions, that's totally fine. All of these choices can be changed later without fuss.

3. Update `.gitignore` and `package.json`.

Add the .wrangler/ directory to .gitignore.

Now, it's time to connect some dots with package.json scripts. Here's how I've done it:

"scripts": {
  "11ty:build": "npx @11ty/eleventy",
  "11ty:watch": "npx @11ty/eleventy --watch --quiet --ignore-initial",
  "11ty:benchmark": "DEBUG=Eleventy:Benchmark* npm run build",
  "build": "11ty:build",
  "util:rimraf": "npx rimraf _site",
  "util:killport": "npx kill-port --port 8787",
  "start": "npm-run-all util:rimraf util:killport 11ty:build --parallel 11ty:watch wrangler:dev",
  "wrangler:dev": "npx wrangler dev --live-reload",
  "wrangler:deploy": "npx wrangler deploy"
},

No two package.json files are alike, so I'll just step through the important stuff:

11ty:build: Just do the build, nice and simple
11ty:watch: Run build if something changes, used for local dev only. We're using --ignore-initial here because we want to run a regular 11ty build beforehand
start: wrangler gets a bit confused if _site isn't ready to go. That's why we run the regular build before running the watch build

How you handle this is very much up to how you handle your own build, but they key takeaway is that your 11ty --watch process should run in parallel with wrangler dev. This will allow live reload to work.

4. Test and deploy

Run npm run start (or however you kick off your local stuff), and see if everything works as expected. You'll note wrangler spins up your Worker on 8787. You can change that (and many other settings) if you want.

If everything is all okay, run the deploy script npm run wrangler:deploy (or just run it directly with npx wrangler deploy).

NOTE: If you set up your domain as a route in the wrangler.jsonc but Cloudflare DNS already has a record assigned for that domain/subdomain, you will likely get an error here. You'll need to manually delete it via the Cloudflare DNS web UI before you're allowed to deploy. Keep a screenshot of those settings before removing, just in case you want to roll back.

5. Optional: Connect the Worker to your Git repo

This is optional. If you're fine running the build and deploy commands locally and manually, you don't need this. Enabling this connection will ensure any merge to main will kick of a new build and deploy in Cloudflare instead. I couldn't find a way to configure this in wrangler.jsonc yet, but the docs recommend creating this links via the UI in any case.

And you're done!

I'll dive into moving functions over soon. Until then, I've shared some example wrangler config snippets that should hopefully give you a head start.

If you're getting stuck with your move, I'm happy to chat and help where I can, just ping me on Mastodon.

Thank yous

Big thank you Cassey Lottman for their helpful feedback on not_found_handling!

WebC at scale

2024-08-07T00:00:00Z

When setting out to build Capital Brief, 11ty (v2 at the time) supported on-demand builders in Netlify via the 11ty serverless plugin. This allowed me to use a build strategy along the lines of:

Build the most recent stories and first page of each index
Use on-demand builds for the rest

This gave us predicable build times and ensured the pages we expected humans to read were super fast.

Sounds good right? Unfortunately for me:

The latest version of 11ty (v3 at time of writing) removes the Netlify based serverless plugin, and
The long tail of on-demand pages (which by design, are a bit slower on first access) has a negative impact in Google PageSpeed Insights

So the new build strategy is: build all the things.

All fun and games in theory, but the second the rubber hit the road, the build failed with:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

I gave the process 8GB of RAM: npx --node-options='--max-old-space-size=8192' @11ty/eleventy --serve --quiet... and got the same error.

Uh oh.

So I started breaking things up into smaller chunks to see what part of the build was the most expensive. Here's what I found:

Use @raw instead of @html

Since the good old days, I've used a layout pattern like:

base.webc

<!doctype html>
<html
  <head></head>
  <body>
    <template webc:nokeep @html="content"></template>
  </body>
</html>

page.webc

---
layout: base.webc
---

<custom-header></custom-header>
<main @html="content"></main>
<custom-footer></custom-footer>

I'm pretty sure it's a standard pattern, and from my first read of the WebC docs, the usage of @html seems right?

- Content returned from the @html prop will be processed as WebC.
- Using [@raw] will prevent processing the result as WebC.

Turns out that in the context of a layout, using @html for content is not necessary, and just super expensive.

Out of everything I discovered, this is the biggest, easiest, and most practical win. I haven't dug into the internals to work out why, but this change is what allowed the build to complete without running out of memory.

Avoid nesting WebC components, where practical

This change had a smaller impact, but I noticed improvements when reducing component and layout nesting, particularly where the data being passed through was chunky. As a follow up example from above, instead of splitting the layouts into base + page, I now use use just page.

page.webc

<!doctype html>
<html
  <head></head>
  <body>
    <custom-header></custom-header>
    <main @raw="content"></main>
    <custom-footer></custom-footer>
  </body>
</html>

Get expensive data into required shape

If you're in a position where every millisecond counts, you can shave a few off by getting complex or looped data ready as HTML in your data first, then use <div @raw="related.html"></div> instead of <div webc:for="related.items">...</div>.

I actually rolled this change back in the end, as the many costs of the change outweighed the benefit. I much, much prefer to handle the HTML in the template rather than in data.

TLDR;

Use of some WebC props get expensive as the number of files to build grows.
Using @raw instead of @html will provide the biggest performance boost, particularly if used in layout files.
Nesting of WebC components can slow things down, especially if you're passing large objects or content as props.
You can trim a few milliseconds off by pre-processing complex HTML, but doing this might not be worth the many tradeoffs.

Nested pagination with 11ty

2024-06-27T00:00:00Z

Let's kick off with a caveat: I don't rely on 11ty collections for building indexes and loops and stuff. I pull down the data I need from a CMS, get it into shape, then use the cleaned up data in WebC template files. This keeps almost all data related transformations in one place (the data file), and allows the templates to be super clean.

Everything that follows here is based on that usage of 11ty data, but I reckon you should be able to follow a similar pattern when building a new collection, if that's more your jam.

Let's say we have a _data/all.js file that grabs all articles from a CMS, ending up with something like this:

const articles = [
  {
    title: 'Example article',
    authors: [{ slug: 'jake-dog' }, { slug: 'susan-strong' }],
  },
  {
    title: 'Another example',
    authors: [{ slug: 'finn-human' }],
  },
  [etc...]
]

Now, we want to create some author indexes (/author/jake-dog/), that are also paginated (/author/jake-dog/2/).

A data structure that I reckon makes sense here is an array of authors that each have an array of articles.

Unfortunately for us, 11ty pagination only handles a single data set: you can either loop through the authors, or the authors articles, not both. We could solve this by just creating an individual template file for every author, but that doesn't sound like fun. Let's come up with something cleverer! Inspired by this post and this thread, I ended up forming an array of authors that instead looked like this:

const authors = [
  {
    path: '/author/jake-dog/',
    author: 'jake-dog',
    articles: [ [Object], [Object], [Object] ]
  },
  {
    path: '/author/jake-dog/2/',
    author: 'jake-dog',
    articles: [ [Object], [Object], [Object] ]
  },
  {
    path: '/author/susan-strong/',
    author: 'susan-strong',
    articles: [ [Object], [Object], [Object] ]
  },
  [etc...]
]

Now we have a flat array, where each object represents an author index page to be built. Based on that, the WebC template code for our author index pages looks like this:

---js
{
  pagination: {
    data: 'all.authors',
    alias: 'item',
    size: 1,
  },
  permalink: ({ item }) => {
    return item.path;
  }
}
---

<h1 @text="item.author"></h1>
<ul webc:for="article of item.articles">
  <li @text="article.title"></li>
</ul>

Clean as!

P.S. I'm not a huge fan of the AI-fication of everything right now -- but I ain't gonna lie -- I use ChatGPT quite a bit for tasks like 'pls make this data structure look more like this one over here'.

TLDR;

As of today, 11ty only supports a single data set for pagination, and does not have a method to handle further pagination of any nested data sets.
You can work around this by creating a flat array, where each object contains enough info to build a single page.
Where you do this work is totally up to you. I like to do it in _data, not in the template.

Magic links are great, until they're not

2024-06-19T00:00:00Z

It was a short discussion when determining the auth method for Capital Brief. Some flavour of passwordless was a must, and when thinking back to passwordless experiences that brought me joy, Slack came to mind.

I remembered opening Slack on my phone for the first time. I entered my email address and hit sign in, expecting a password prompt to follow. But instead, bing! An email with a sign in link. I opened the link and... whoa, I am signed in to Slack. Just like magic.

That flow felt great to me! I wanted to replicate that.

I experimented with a few auth providers, chose one, built the thing and launched it.

Things seemed to be going well, but then:

“When I try to sign in, the site says the link has expired.”

Uh oh, that doesn't seem like a nice experience. Turns out we have some readers that work in, let's say, fairly corporate environments. Their security teams want to protect their people from phishing. That's good!

Unfortunately, checking emails for phishing requires an automated process to open links, and... oh no, the link checker has the sign in token now, not the person trying to sign in. That's bad.

We had a chat with our US based auth provider and they said they already have checks on their end to stop bots from expiring the link. Perhaps we use different security tooling configs here in Australia? With no quick fix in sight, I switched those readers over to one-time password (OTP) instead. Besides the initial friction this seemed to work really well, so we didn't worry to much about magic links, until:

“The site keeps signing me out.”

This one took a while to figure out. So let's say a reader is using the LinkedIn app and clicks through to a Capital Brief story. They see the paywall, get a magic link, sign in, read the story, close the app and do it all again the next day. But wait, now the site says they're not signed in anymore? What gives?

When a person opens a web link from a mobile app, the link typically doesn't open in the person's default browser. The link will instead open up in a browser embedded into the application (a "webview") that does not share the state, sessions or cookies of the person's default browser. The person wasn't getting signed out – they were never being signed in to the webview in the first place. Instead, they're signed in to whatever browser opened when they clicked the sign in link from their email.

We directed people to the plain text link they could copy and paste into the desired browser (or webview), but this felt... extremely suboptimal. Then:

“We can only receive work emails in Teams, and links open in a sandboxed browser.”

Lmao, okay, we can't fix this at all.

Earlier this year we removed magic links and switched all users to OTP, to the joy and delight of our support team (hello Dave).

So if you're building an application, maybe you'll be fine? I think Slack still use 'em? But if you're building a website, it'd recommend sticking with OTP.

TLDR;

Link checkers/email security tools can accidently expire magic links.
The magic link flow is super janky when trying to sign in to a website that was loaded in a webview.
Some people straight up can't make use of magic links to sign in to websites because of security policies.
Magic links aren't ready for wide adoption as a flow for signing into websites, so we switched to OTP instead.

Ben White — Blog

Getting through the backlog

Arc Raiders

Clair Obscur: Expedition 33

Mixtape

First principles

Migrating an 11ty site from Cloudflare Pages to Workers

1. Install wrangler and login

2. Configure your Worker

3. Update .gitignore and package.json.

4. Test and deploy

5. Optional: Connect the Worker to your Git repo

Thank yous

WebC at scale

Use @raw instead of @html

Avoid nesting WebC components, where practical

Get expensive data into required shape

TLDR;

Nested pagination with 11ty

TLDR;

Magic links are great, until they're not

TLDR;

1. Install `wrangler` and login

3. Update `.gitignore` and `package.json`.