Loomwork: The Framework That Builds Everything
Why Build a Framework
We kept building sites. Johnny Solarseed, Boopadoop, Codenoscopy, this portfolio - each one started the same way: scaffold an Astro project, set up content collections, configure Cloudflare deployment, build a header, build a footer, write the same CSS reset, wire up the same dark mode toggle.
After the fourth time, the pattern was clear. The framework wasn’t an abstraction exercise - it was an extraction. Take the pieces that were identical across every site and make them reusable.
What Loomwork Is
An Astro-based publishing framework. Content collections, MDX pages, Cloudflare deployment. Write markdown, push to GitHub, auto-deploy in 30 seconds.
What makes it different from “just use an Astro starter”:
Content-First Architecture
Content collections with typed schemas. Pages, posts, projects, cases, timelines - each collection has a defined shape. You write JSON or MDX, and the framework handles rendering, routing, and navigation.
Theme System
Ten built-in themes. Each includes light + automatic dark mode + curated Google Fonts. Switch themes by changing one string in your config file. Every site in the portfolio runs on Loomwork, and switching between Manuscript, Brutalist, and Terminal transforms the entire reading experience.
Mobile PWA Editor
This is the weird one. Loomwork includes a built-in mobile editor that lets you create and publish content from your phone via the GitHub API. Write a post on the bus, commit it, and Cloudflare Pages auto-deploys it.
No CMS. No admin panel. Just a PWA that talks to GitHub.
Reader Controls
The floating gear icon gives visitors control: dark mode, font size, content width, table of contents visibility, focus mode. Preferences persist in localStorage. The site owner never has to think about it.
Page Templates
- Default - standard content page with optional TOC
- Guide - documentation-style with sidebar navigation
- Landing - marketing layout with full-width sections
- Longform - the split-panel layout you’re reading now
Each template is a layout component. The frontmatter template field selects which one renders.
The Architecture
CSS Load Order
global.css- framework reset, base prose, default variables (:where(:root)for zero specificity)- Theme CSS - loaded from
public/themes/{name}.css, sets:rootvariables site.css- site-specific overrides, always wins
This means themes can completely transform the visual identity, and site authors can override anything they don’t like.
Zero Build Tooling for Themes
No PostCSS. No Sass. No theme compilation step. Themes are plain CSS files that set CSS custom properties. This was a deliberate decision born from the Campfire 2 failure - the less tooling between a theme author and the browser, the better.
Cloudflare-Native
Built for Cloudflare Pages + Workers. SSR-capable with Cloudflare’s Astro adapter. Workers for dynamic routes (the contact form, the mobile editor’s GitHub proxy). KV for session state. Everything runs on the edge.
The Dogfooding Loop
Every site we build uses Loomwork. Every pain point we hit becomes a framework improvement. The theme migration you’d see in the commit history? That was real - the portfolio was using hardcoded CSS variables that broke theme switching. The fix required touching three files and ~170 token replacements. That experience directly led to better documentation about how site.css should work.
What’s Next
Loomwork 2.0 shipped the theme system. The near-term roadmap:
- Post collection improvements - blog-style pages with dates, tags, RSS
- Search - client-side full-text search across all content
- i18n foundations - not full localization, but the plumbing to support it
- More templates - portfolio grid, changelog, comparison pages
The goal isn’t to compete with Nextra or Starlight. It’s to be the framework where one person can build a complete, professional site in an afternoon - and modify every pixel of it without fighting abstractions.