Note: This article was first published in German at WP Munich.
When Cloudflare introduced EmDash as a new alternative to WordPress in early April 2026, what mattered was not so much the product itself, but what the launch made visible. The comparison exposes an old weakness in Gutenberg: content ultimately gets stored as HTML in post_content, not as a structured data model.
That this is a fundamental problem is not a new observation. The debate around structured data in WordPress has followed Gutenberg from the very beginning, and I have been criticizing this lack of support since 2017. It was already clear early on that content on the web would become more than pure output. It needs to be categorized, sorted, transformed, and moved into new contexts. That is exactly what determines how future-proof a CMS really is today.
So the point is not whether Gutenberg is a good editor. The point is that Gutenberg does not take its internal structure seriously enough when it comes to storage. As long as content is primarily stored as HTML, structure remains something that has to be extracted again when needed. In a web reality shaped by APIs, headless architectures, and AI-powered workflows, that increasingly feels like a design flaw WordPress is still carrying around.
Why EmDash CMS Matters Right Now
Cloudflare is not positioning EmDash CMS as just another new CMS but as an alternative to a specific way of storing and processing content. That is exactly why this launch matters. EmDash CMS uses structured content instead of serialized HTML and relies on Portable Text, a JSON-based rich text format. In doing so, it separates content from presentation at exactly the point where Gutenberg still ties the two too closely together.
A look at Gutenberg’s architecture shows just how fundamental that difference is. In the official WordPress documentation on Data Flow and Data Format, WordPress describes the block tree as existing in memory while editing, while post_contentis what ultimately gets stored. The page on Markup Representation of a Block also shows that this storage happens through HTML with block comments. In other words, Gutenberg works with structure internally but does not treat that structure as the primary data model when saving content.
That is why EmDash CMS matters right now. The launch is not just a product comparison. It creates a contrast that makes Gutenberg’s architectural weakness very easy to see. When a new CMS in 2026 openly treats content as data, the storage question is no longer a technical footnote. It is an architectural question.
The Real Problem Is Not the Editor, but the Storage Format
Gutenberg’s weakness does not show up while writing. It shows up when content is supposed to live beyond the editor. As long as a text is only created in WordPress and then rendered, the storage decision barely stands out. It only becomes relevant when content needs to be processed through interfaces, reworked, or moved into other systems. That is the moment when an internal implementation detail turns into a structural limitation.
The reason is simple: Gutenberg does not store its content structure as the primary data model but as serialized output in post_content. The WordPress documentation on Data Flow and Data Format explicitly describes this separation. What exists as a block structure in the editor is converted into an HTML-based format when saved. The page on Markup Representation of a Block shows how that structure is preserved through comment markers and embedded attributes.
That works, but it comes at a cost. As soon as other systems are supposed to understand not the output but the meaning of a piece of content, that structure first has to be extracted again from the stored HTML. WordPress provides parse_blocks() as the central function for that purpose. The fact that the official reference points to memory overhead, and that WP_Block_Processor was later introduced as a more efficient access layer makes the friction pretty clear.
It becomes even more obvious with WordPress VIP’s Block Data API. It exposes Gutenberg content as structured JSON and is explicitly justified as a way to avoid HTML parsing. That is the key point. If a system first needs an additional API to expose its content in a form that can be used sensibly by headless architectures, GraphQL, or other applications, that mostly shows where the original storage logic runs into its limits.
That also makes it clear why EmDash CMS is such an interesting comparison. The contrast does not just show that another path is possible. Above all, it shows how much additional effort WordPress now has to invest just to get back to the structure it never truly prioritized when saving content.
Why WordPress Framed This Decision the Way It Did, and Why That Still Falls Short
WordPress did not land on HTML in post_content by accident. It justified that decision deliberately. In the official documentation on Data Flow and Data Format, the argument is about compatibility, a single source of truth, and avoiding competing storage models. The Block Editor FAQ makes a similar case and contrasts the HTML-oriented approach with the idea of storing content as JSON in post meta instead.
From our perspective, that rationale still falls short. It thinks too much from the logic of existing WordPress structures and not enough from the question of what content needs to be able to do in the future. Compatibility is a valid point. But it is not a substitute for a clean structural model.
The problem was visible from the start. As soon as content is meant to be more than rendered output, it is not enough to drag structure along implicitly inside HTML. At that point you need a data model that does not merely display content but also makes it machine readable, sortable, and processable. That is exactly the criticism we raised early on in our discussion of structured data in WordPress.
Looking back, the reasoning now feels less like a durable solution and more like a defensive decision in favor of short-term system stability. The price is still visible today. Structure has to be extracted from HTML afterward instead of being the foundation of the content from the start.
EmDash CMS Shows What Another Path Can Look Like
That is why EmDash CMS is more than just a new CMS. What matters is not that Cloudflare is building a publishing system. What matters is that EmDash CMS addresses the storage question at exactly the point Gutenberg has avoided it until now.
The crucial difference is architectural. EmDash CMS uses Portable Text, a JSON based rich text format, and cleanly separates content from later presentation. That is not a minor technical detail. It reflects a fundamentally different attitude. Content does not become structurally readable only after rendering or parsing. It already carries that structure from the beginning.
That is exactly where the real provocation for WordPress lies. EmDash CMS implicitly questions the assumption that HTML is a sensible place to store content permanently. If content now moves through different systems as data objects, then HTML is not the foundation anymore. It is just one possible output form. EmDash CMS treats that reality as its starting point. Gutenberg still treats it more like a problem to solve afterward.
Of course, that does not automatically mean EmDash CMS is already the final answer to everything. The project is still too new for that. But the launch makes one thing very clear: how content is stored is no longer a technical footnote. It determines how well a CMS can connect to the reality of modern content.
What WordPress Is Now Trying to Repair After the Fact
The clearest sign of the real problem is that WordPress VIP provides Gutenberg content as structured JSON through the Block Data API. This API does not simply extend Gutenberg. It compensates for a storage model that never put structure first. WordPress VIP states the benefit plainly: it is meant to avoid HTML parsing.
The same applies to parse_blocks() and WP_Block_Processor. What you see here is not some luxury feature, but the need to turn stored content back into a usable structure efficiently. The fact that WordPress needs dedicated processing logic and extra optimizations for that makes the underlying design flaw more visible, not less.
That is why the current development around WordPress feels less like consistent forward motion and more like symptom management. More and more tools are being built just to regain the structure that was never properly prioritized at storage time. And that is exactly where the difference from EmDash CMS becomes sharp. There, structure does not need to be recovered. It is part of the content from the start.
What Gutenberg Can Learn from EmDash CMS
The most important lesson from EmDash CMS is not that WordPress is suddenly obsolete. The real lesson is that content on the web now has to be thought about differently. As long as content is understood mainly as output, HTML as a storage format can still seem good enough. But once content moves into new contexts through APIs, multiple frontends, personalization, and AI systems, that logic no longer holds. At that point, structure cannot be something you expose afterward. It has to be stored from the beginning.
For Gutenberg, that is the real challenge. Not because the system lacks blocks or because it is internally unstructured. But because that structure still has not been made, the true core of the storage model. That is why WordPress keeps producing more helper layers around Gutenberg, while EmDash CMS answers the same question one level earlier. The core architectural question is no longer just how content gets edited. It is in what form a system fundamentally understands its content over time.
And that points to a bigger consequence beyond WordPress. The web does not just need more modern editors. It needs systems that take content seriously as data again. EmDash CMS makes that point so visible because it does not merely promise a new interface. It represents a different understanding of content. For Gutenberg, that is not a minor nudge. It is a very direct reminder of where its design flaw has been sitting for years.