Why we chose blocks over WYSIWYG — and what it cost us

Every CMS makes a fundamental choice early on: give authors a blank canvas, or give them structured building blocks. WordPress was built around the canvas. We chose blocks.

That decision has consequences, some obvious, some only visible years later. This post is about why we made that choice, what it enabled, and what it genuinely made harder.

The WYSIWYG trap

Rich text editors feel productive. You type, you bold, you drag in an image. It looks like what you'll publish. That immediacy is powerful.

But what you're actually producing is presentation-led HTML that may or may not be structured. A heading that looks like a heading might be a bold paragraph. An image might be inline with no alt text, no caption structure, no semantic relationship to the content around it. A two-column layout might be a table, or a div with inline styles, or something that only works in one browser.

The output is unpredictable. It can't be reliably parsed, restyled, or repurposed. It's optimised for the moment of writing, not for anything that happens afterward.

This matters more now than it did five years ago. Structured data, multi-channel publishing, API consumers, AI systems that extract meaning from content, all of these need predictable output. WYSIWYG doesn't give you that.

What blocks actually solve

A block-based editor constrains what authors can do, and that's the point. Each block is a typed, structured unit of content.

• A Hero block has a heading, subheading, image, and call-to-action. Not a rich text blob that happens to look like a hero.

• An FAQ block has question-answer pairs. Not bold text followed by regular text.

• A Pricing block has plans, features, and price fields. Not a hand-built table.

Because each block knows what it is, the system can:

• Generate Schema.org markup automatically. An FAQ block produces FAQPage JSON-LD without the author thinking about it.

• Render differently per context. The same content can output a themed frontend page, an API response, or an AMP version, because the data is structured, not presentation-locked.

• Enforce consistency. Every hero looks like a hero. Every CTA has the required fields. The design system is respected by default, not by discipline.

• Survive redesigns. When you change themes, blocks re-render cleanly. WYSIWYG content breaks because it carries its own styling assumptions.

What it cost us

Honesty matters here. Blocks aren't free.

Authors have less freedom. You can't do whatever you want in a block editor the way you can in a rich text field. Some authors find this frustrating, especially those coming from WordPress's classic editor. The constraint is the feature, but it doesn't always feel that way.

Content migration is harder. Importing WYSIWYG HTML into a block system means parsing unstructured content into structured blocks. There's no reliable automated way to do this. It requires editorial judgment. For sites with thousands of legacy pages, this is a real cost.

Simple pages feel over-engineered. A page that's just three paragraphs of text doesn't need a block system. It needs a text field. We've had to find the right balance between structure and simplicity, and we haven't always gotten it right on the first try.

The learning curve is real. Authors who've used WordPress for a decade have muscle memory for WYSIWYG. Blocks require a different mental model: you're assembling a page from components, not writing a document. That shift takes time.

Why the tradeoff is worth it

The costs are real but bounded. The benefits compound over time.

Every block you create today produces clean, structured output that works with whatever comes next: new themes, new frontends, new API consumers, new discovery channels. WYSIWYG content is locked to the assumptions of the moment it was written.

WordPress recognised this too. Gutenberg is WordPress's belated attempt to move from WYSIWYG to blocks. But it's retrofitted onto a system that spent 20 years optimising for unstructured content. The data layer, the theme system, the plugin ecosystem, all of it assumes HTML blobs. Blocks are bolted on top. In TallCMS, they're the foundation.

That's not a small difference. It's an architectural one. And architectural advantages are the kind that get harder to replicate over time, not easier.

The principle behind the decision

We'd rather give authors a system that produces excellent output by default than a system that produces anything they want. Constraints that serve the reader, the design system, and the long-term health of the content are worth the short-term friction they create for the author.

How this shaped TallCMS

This decision didn't just affect the editor, it shaped the entire architecture. Because every piece of content is a typed block with known fields, TallCMS can generate Schema.org markup per content type without author effort. Themes can be swapped without content breaking. The API returns structured data, not serialised HTML. And when we built multisite support, per-site content isolation worked cleanly because blocks are data, not layout.

None of that would be possible if the content layer was a rich text field.

Not every CMS should make this choice. But for content that needs to be structured, maintainable, and discoverable across channels, it's the right one.

The editor is temporary. The output has to last.