I Rebuilt a WordPress Theme and Realized I'd Been Cargo-Culting Dependencies for Years

Last year, I inherited a WordPress site for a client that was running on a theme with a build pipeline so complex that even the original developer couldn't explain why half of it existed. Tailwind, PostCSS, Autoprefixer, Alpine.js, all for a simple blog theme. When a new WordPress update broke something in the pipeline, the whole development environment collapsed. That's when I read about Cleora v2's rebuild philosophy, and it hit me hard: I've been doing this wrong for years.

I'm not talking about those massive marketing sites where every tool is justified. I'm talking about the mid-sized blogs and editorial projects where we developers add layer upon layer of abstraction until the project becomes harder to maintain than it needed to be. Cleora v2 is a direct challenge to that thinking, and honestly, it's made me reconsider how I approach WordPress theme development entirely.

The Problem Nobody Talks About Publicly

Here's what rarely gets said in tech communities: dependencies are debt. Not the kind of debt that's always bad, sometimes the interest payments are worth it, but debt nonetheless. When I first read that Cleora started with Tailwind and Alpine, I thought, "Of course it did. That's the modern way." But then the authors did something unusual: they asked if that debt was actually serving the project.

The original Cleora wasn't broken. It worked fine. But maintaining it meant managing a build pipeline for something fundamentally simple, a reading-optimized blog theme. Every update to npm dependencies became a small ceremony. Every time a developer wanted to tweak something, they had to understand the entire stack.

The rebuild removed Tailwind, Alpine.js, and the entire npm build pipeline. Not because these are bad technologies, they're genuinely excellent, but because a minimal editorial theme doesn't need them. That distinction matters. It's not anti-modern; it's pragmatic.

What Actually Changed, and Why It Matters

The technical decisions in Cleora v2 reveal a philosophy I've been slowly adopting myself: optimize for the work you're actually doing, not the work you imagine you might do someday.

Instead of Tailwind's utility class approach, they hand-authored CSS. This removes the build step entirely, you can inspect the theme directly. The stylesheet downloads as-is to the browser. For a blog theme, this means faster initial render and zero build complexity.

Instead of Alpine.js, they wrote approximately 5KB of vanilla JavaScript for mobile navigation and toggles. That's it. No framework overhead for something that doesn't need one.

The most interesting architectural change, though, is how they unified the editor and frontend experience using CSS custom properties and theme.json. This solves a real WordPress pain point: the block editor looking nothing like the published site. By defining design tokens once, colors, typography, spacing, both environments speak the same visual language.

/* Design tokens defined once, used everywhere */
:root {
 --font-primary: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto;
 --font-serif: Georgia, "Times New Roman", serif;
 --measure: 65ch;
 --color-text: #1a1a1a;
 --color-accent: #0066cc;
 --spacing-unit: 1rem;
}

/* Reused consistently across the frontend */
.post-content {
 font-family: var(--font-serif);
 max-width: var(--measure);
 color: var(--color-text);
}

They also ditched web fonts for system font stacks. This isn't retro or minimalist for its own sake, it's a practical choice about what matters for reading-first content. Web fonts add network requests and can cause layout shift. System fonts render immediately.

My Take: This Challenges How We Train Developers

I find myself genuinely conflicted. Part of me loves this direction. I'm tired of maintaining npm scripts for projects that don't need them. But another part of me worries we're training a generation of developers who reach for Tailwind and Alpine instinctively, without asking if they're necessary.

Cleora v2 proves you can build something modern and polished without the default dependency stack. But that doesn't mean every theme should follow this path. A theme supporting multiple content types, extensive customization, and complex editor integrations might genuinely need those layers.

The real lesson isn't "don't use frameworks." It's "understand why you're using them." Cleora's authors knew their constraints and optimized accordingly. That's craftsmanship.

What would I do differently? Maybe I'd keep a light build pipeline just for development convenience, autoprefixing, minification, maybe a dev server. But their point stands: you don't need it to ship. The theme works perfectly fine without it.

The Question I'm Sitting With

How many of my own projects are running unnecessary tooling? I've got at least two WordPress sites where I could strip out half the dependencies and improve maintainability. Have you looked at your own dependencies recently and asked the same question?

Source: This post was inspired by "Cleora v2: Rebuilding Our WordPress Theme From the Ground Up" by Dev.to. Read the original article