5 min read
I Got Tired of Recipe Blogs, So I Built an Extension

I like to cook. What I do not like is the modern recipe blog.

You know the genre. You search for “banana bread,” click a promising result, and are immediately greeted by 2,000 words about the author’s childhood summers, a carousel of ads, an autoplaying video that follows you down the page, two newsletter popups, and a “Jump to Recipe” button that scrolls you to approximately the right spot. The recipe — the four ingredients and six steps you came for — is maybe one percent of the page, buried in the middle of a content-marketing machine.

I get why it’s like this. SEO rewards word count, ads pay the bills, and a bare list of ingredients doesn’t rank. I’m not mad at the people writing them. But as someone standing in a kitchen with flour on my hands trying to read the next step on a greasy phone screen, I am, in fact, a little mad.

So I built Readable Recipes — a browser extension that pulls the recipe off the page and shows it to you clean. Title, ingredients, steps, times. Nothing else. It’s free, and it’s out now:

Side projects are how I learn

I’ve got a confession that won’t surprise anyone who does this for a living: the recipe-blog rage is real, but it’s also a pretext. Side projects are how I learn things, and I’d been looking for an excuse to get into a few areas I hadn’t touched.

Browser extension development was the big one. I’d never shipped a real extension, and it turns out the gap between “hello world content script” and “something that works reliably across Chrome and Firefox, survives the browser killing your background process, and doesn’t get into a fistfight with ad scripts” is enormous. That gap is where all the fun is.

It was also a chance to push on the stuff I actually care about — design patterns and writing code that’s a pleasure to maintain. A recipe extractor sounds trivial until you look closely, and then it’s a genuinely nice little playground: a pluggable adapter pattern for the different formats sites use, a reducer for durable state, a scoring system that measures bad data instead of guessing at fixes. I wrote a whole series of articles on the project page digging into those — start with how the extraction engine works if that’s your thing.

Two new tools I’m now a fan of

This project was my first time using a couple of tools, and both earned a permanent spot in my toolbox.

WXT is a framework for building browser extensions, and it’s the kind of tool that makes you wonder how you lived without it. It gives you Vite-powered hot reload, generates the manifest for both Chrome (MV3) and Firefox (MV2) from a single config, and wraps the storage and messaging APIs in something type-safe. My previous mental model of extension dev was “shell scripts and manifest templating and suffering.” WXT deleted that entire category. It doesn’t do everything — there’s a whole class of production concerns (service-worker lifecycle, concurrency, durable queues) it leaves to you, which I wrote about separately — but the parts it owns, it owns well.

Biome replaced ESLint + Prettier for me, and the headline is just: it’s fast, and it’s one tool. One binary, one config, lint and format together, no plugin-resolution archaeology when something breaks. There are tradeoffs — it lints Vue <script> blocks but not <template>, so for a template-heavy app you might still want the ESLint route — but for a project this size it was an easy, happy default. I didn’t miss the old setup for a second.

Neither tool is the point of the project, but that’s sort of the whole idea of a side project: pick something you’ll genuinely use, and let it drag you through a few new tools along the way.

Open source, eventually

Here’s where I’m headed: I want to open-source this. Probably. Eventually.

I’m hedging on purpose. There’s a real decision to make first — there’s a dataset angle to the project (the extension can contribute anonymous, non-copyrightable recipe facts to build a shared, cleaned-up cache; I wrote about how that works without collecting anyone) and that interacts with how I license the code. I’d rather think that through properly than slap a license on it in a hurry and regret it. But the direction I want to go is out in the open, in line with my general open-source goals, and I’ll write about it when I get there.

In the meantime: it’s live, it’s free, and it has spared me a lot of scrolling past stories about somebody’s grandmother to find out how long to bake the bread. If you cook and you use a browser, give it a shot — and if you find a site it chokes on, that’s exactly the kind of bug I want to hear about.

Now, back to the banana bread.