Why I Still Bet on WordPress

Every few months, someone declares that WordPress is dead.

I keep building outside it — and still coming back.

Not because I’m stuck.

Not because I don’t know better tools.

But because after a decade of shipping real products, WordPress continues to win in places most comparisons ignore.

Yes, I’ve built outside WordPress

I’ve pulled Gutenberg out of WordPress entirely to build editor experiences. I’ve shipped headless setups where WordPress is nothing more than a content API. I’ve built React applications that never touch PHP. I’ve worked on projects where WordPress would have been the wrong choice — and I knew it.

I’m not betting on WordPress because it’s all I know.

What I got wrong about headless & decoupled frontends

For a long time, I believed headless and fully decoupled frontends were the inevitable future — and not without reason. I chased cleaner architectures, React-first workflows, and the promise of total flexibility. In many cases, they delivered exactly that.

What I got wrong was treating this approach as a default instead of a tool.

The hidden cost wasn’t performance or technical complexity — it was friction. Previews broke. Editorial workflows slowed down. Simple changes required deploys. Teams gradually lost autonomy in ways that were easy to ignore at first.

Headless isn’t the problem; uncritical adoption is. Over time, I learned that most projects don’t need maximum flexibility. They need reliability, ownership, and a stack that doesn’t fight back.

That realization is a big part of why I still bet on WordPress today.

What Gutenberg quietly got right

Gutenberg’s value isn’t the editor — it’s the architecture underneath.

Blocks are portable UI contracts. A block defines its structure, its attributes, its allowed variations. That definition travels with the content, not the theme. Switch themes, the content survives. Query blocks programmatically, the structure is already there. This is what years of shortcode chaos never gave us.

Then there’s the shift toward declarative configuration. block.json and theme.json moved WordPress away from scattered PHP hooks toward predictable, tooling-friendly JSON. You can lint it, version it, generate it. It’s not perfect, but it’s a direction that finally aligns with how modern development works.

The separation of structure from styling matters more than people realize. Classic WordPress tied content to presentation so tightly that switching themes meant rebuilding pages. Blocks broke that coupling. Structure lives in the content layer; styling lives in the theme. Long-term projects benefit from this in ways that aren’t obvious until year two or three.

Blocks also scale better than their reputation suggests. Patterns, variations, and InnerBlocks let you build component systems without page builder bloat. Agencies are shipping block libraries now — not plugins full of shortcodes, but composable pieces with real contracts.

Gutenberg is misunderstood by both its critics and its fans. Critics see it as a slow page builder chasing Elementor. Fans oversell it as a design tool for non-developers. Both miss the point. The real value is that WordPress finally has a content model that isn’t just HTML in a database column. That’s a foundation you can build on for years.