Last week, Cloudflare launched a new CMS called EmDash, which they claim is the “spiritual successor” to WordPress, and a lot of industry discussion ensued.
EmDash is built on Astro, runs serverless on Cloudflare’s infrastructure, is based on TypeScript, and is open source under an MIT license.
I’ve been reading through all the reaction posts, tested it myself in their playground, and like many others have some thoughts about what EmDash really does and doesn’t bring to the table.
But before I get into that, I want to talk about something I see that often happens in tech conversations: the more developer-oriented the product and its messaging are, the more it tends to forget about real life end users.
Developers are interesting. Architectures are interesting. New frameworks, security models, data structures — all interesting. End users, on the other hand, are just regular people trying to use a UI to get things done and not break anything. That’s not a very exciting prospect, so they tend to get less airtime in the discussions that shape what what’s getting built.
I saw this firsthand when working on Strattic. At the time, a lot of products were offering headless WordPress setups that were technically impressive but also incredibly limiting for content managers and marketers who depended on the flexibility of WordPress and its plugin ecosystem. The developers loved the architecture, but the people running the actual websites were frustrated – the CMS experience they knew and loved was being taken away from them, bit by bit. Developers told them “but the decoupled architecture is better for you!” but all they wanted to do was preview a post.
Strattic was built to bridge that gap and keep the CMS for the end user intact, because they were never an afterthought in our product thinking – they were the whole point. And I think WordPress has always had the same approach: the end user comes first.
Now back to the EmDash launch discussions: most of it has been about the architecture, which is definitely worth discussing. But what about the people who need to actually use their websites? Where do they fit in?
Keeping this in mind, here’s my breakdown of what EmDash brings to the CMS table, and how much it matters, especially for end users.
What EmDash does better, and why it may not matter (yet)
Plugin security is the headline claim, and architecturally it’s a real improvement – but there are no EmDash plugins yet. WordPress gives every plugin full access to your database and filesystem. There’s no technical mechanism preventing a plugin from doing whatever it wants; you’re entirely trusting the developer. EmDash’s model is different: each plugin runs in an isolated sandbox and has to declare upfront exactly what it needs. It can only do what it declared based on its scoped permissions. This sounds like a very sound approach.
But there are currently zero EmDash plugins. A clean security model with nothing to secure is an easy sell, but let’s see how this actually plays out when there are 10, 20, 100 plugins in their marketplace. The real test will come when complex platform-like extensions like Elementor, Yoast, and more are created. Will the capability model be able to handle them? This is unknown at this time.
Structured content storage is cleaner – for use cases most people don’t have. EmDash stores content as structured JSON using a format called Portable Text which serves clean structured data natively. WordPress stores content as HTML, and Gutenberg specifically adds block structure via HTML comments that then have to be parsed back out when something downstream needs to work with it. Portable Text is useful for systems that need to consume content through an API like mobile apps, headless frontends, or AI agents.
Most website owners aren’t creating mobile apps or headless frontends for their sites. The ability to push content via API is something that makes developers excited and suits high-end architectural needs, relevant for enterprise setups, large media organizations, or teams running complex multi-channel delivery – which describes a small fraction of the sites that actually exist. For the sites that do need some form of content portability, WordPress already covers a lot of ground: it has had a REST API since 2016 and RSS feeds long before that, meaning content is consumable and portable to a meaningful degree without any additional architecture. As for AI agents, WordPress is actively narrowing the AI gap: WP 7.0 is bringing an MCP Adapter and a shared AI Client that will let WordPress function as an MCP server natively. EmDash’s native JSON is somewhat of a head start, but not a permanent one.
Content modeling is built into EmDash’s core UI – but WordPress users have been fine without it. EmDash ships with a UI for creating custom content types and custom fields out of the box. In WordPress, you’ve always needed a plugin for this since it’s not natively supported.
And yet, everyone has been doing just fine thanks to ACF and similar tools which do an excellent job of filling the need. The beauty of WordPress has always been its extensibility, and while it may be ideal for this type of UI to exist in core, as usual creators stepped in and created what was needed.
The AI-assisted developer experience is fast – but WordPress is already there, and getting further. EmDash ships with Agent Skills, structured documentation that gives AI coding tools an opinionated framework for working with the platform. Combined with the built-in MCP server and CLI, an agent can spin up and customize an EmDash site quickly.
But you can already build WordPress sites this way! I built this very site with Claude, and it handled design, development, and problem-solving without any of the EmDash-specific infrastructure people are saying is needed to do this. WordPress’s existing codebase is so well-represented in LLM training data that AI tools are already highly capable with it. WP 7.0 will formalize and extend that with native MCP support, Agent Skills-style documentation, and more. The gap EmDash is pointing to is real, but WordPress is closing it, and it’s doing so on top of an ecosystem that already works.
What EmDash doesn’t offer, and why that comes down to community
If WordPress came along and was like hey everyone, we are releasing a new version that sports a really well architected backend, try it out, and then showed us the EmDash experience, we’d be like um, why did you take away ALL THE THINGS?
I get that EmDash is in its infancy, and there’s more to come, but at the moment the CMS experience feels like we’ve ported back to 2010. I don’t know if it’s because the product truly isn’t geared towards end users, or because you can’t just architect your way into with decades of accumulated community work.
WordPress has thousands of free themes because designers and developers around the world built them, shared them, and kept maintaining them. It has 60,000 plugins covering every imaginable use case — forms, membership, WooCommerce, events, SEO, caching, backup, translation — because an enormous ecosystem of creators built their businesses around it. The content editor works for non-technical people because years of contributor effort went into making it that way, and if you want more, there’s page builders to fill the gap. When something breaks, there are forums, documentation, tutorials, and developers everywhere who know how to fix it. Thanks to all these decades of content, contribution and usage, LLMs have all the knowledge needed to design, build and troubleshoot WordPress sites (like this one).
EmDash has none of that yet, and no architecture makes it appear faster. You can’t design your way to community. It takes time, investment, and a lot of people deciding it’s worth building on.
There’s also the infrastructure independence question. WordPress runs on almost anything — a $5/month shared host, a Raspberry Pi, a major cloud provider. You can move it between hosts over a weekend. EmDash’s serverless approach is geared towards Cloudflare’s own infrastructure, and while you can technically run it on any Node.js server, the architecture is clearly optimized for Cloudflare (for example, it seems that the highly touted plugin security model only works there). That’s a vendor commitment that most WordPress users have never had to think about.
The missing piece: AI that’s actually for everyone
The people EmDash is courting with its AI-native architecture approach and messaging are, in many cases, already well served. The people who aren’t yet well served are the much larger group who chose WordPress precisely because it’s open source, flexible, extensible, and accessible — people who want powerful tools without needing to be power users.
They prefer UIs over CLIs any day.
WordPress has always been good at bringing powerful tools to everyone, and this continues to be the case with AI: version 7.0 is bringing AI-native infrastructure that everyone can easily use and hook into.
There are also packaged AI experiences that don’t involve any kind of connections, like what Automattic is doing on WordPress.com, or Angie, Elementor’s AI for WordPress. You don’t have to wire together tools or set up infrastructure — you just install the plugin and use it. It works within the WordPress environment people already know, without requiring them to understand what’s happening under the hood.
EmDash is a signal
EmDash is a an interesting project with real architectural advantages. But for the overwhelming majority of people who need websites, it doesn’t (yet) offer the features that translate to practical real-world outcomes: themes you can install in a click, plugins that handle the hard stuff, a community with years of solved problems, and a content editor that non-technical people can actually use.
EmDash’s appearance on the scene is good because it demonstrates what the architecture of a modern CMS looks like when you build from scratch with today’s opportunities and possibilities in mind. Competition like this is welcome — it pushes the WordPress ecosystem to look honestly at how it does things. But in practical terms, for the people who actually need to build and run websites via a CMS, EmDash simply doesn’t compare.
