The WordPress community was all abuzz this April 1st when shots were fired from the folks at Astro (owned by Cloudflare). And shots were indeed fired: Astro’s new beta CMS, EmDash, was released with a blog post and documentation aimed squarely at pulling users from the WordPress platform. It looks like Classic WordPress UI and even rocks some CamelCase in the name.
Of course, if you’re going to launch a CMS, it makes sense to position it against WordPress with it’s 40% share of the CMS market and some traces of blood in the water.
It’s easy to fall on either of two sides of the conversation: this is a WordPress killer versus this has zero chance at dethroning the massive WordPress community. I’m not interested in either take, because it’s complex and ultimately, time will tell how much Cloudflare continues to invest in this project (and if Astro + a CMS is as appealing as Astro itself is).
Instead, I thought it might be useful to see what features do make EmDash compelling, and what lessons WordPress can learn from the platform. I took it for a spin and, while there were some major rough edges and error messages, it was still an interesting experience (though they should really call it an alpha, not a beta). I have a lot of questions, but let’s focus on what’s most intriguing about this early version.
Caveat 1: I’m going to compare this to core WordPress, block themes, Gutenberg, etc. The concepts apply to most page builders, but I just want to focus on core.
Caveat 2: I’ve only played with EmDash for a few hours. I may be wrong in some of my assumptions here.
Front-end Freedom
Let’s start with the main selling point: Unlike the rigid structures of the WordPress block editor, EmDash offers total freedom to build front-end markup however the developer chooses. Pairing that with something like Claude Code means you’re getting decent designs up in minutes, probably less.
To be clear, this starts as static content, but that’s ok. In a WordPress block theme, all content is essentially dynamic, meaning it’s built to be visually editable by default and then gets compiled. You can still make WordPress fast with a good page cache or an SSG plugin, but you’re not throwing static content up by default.
With Astro, everything is fairly static until you determine it’s going to be editable. There are posts and pages with a simple content field, but if you ask Claude for a landing page, it’s going to start by generating a static page. Then if you want parts to be editable, you can make custom fields or “collections” of data for it to pull from the CMS.
There is a front-end visual editor, but for now it only handles simple text updates. What happens when the user wants to move one section below the next section, or add a button and change the background color? I’m pretty sure that means development time, unless we’re going to see a return to massive ‘flexible content’ repeater fields.
Takeaway for WordPress: We need more flexibility for custom HTML and CSS in the block editor, or else we need a more robust set of opinionated agent skills to make building in the block editor faster. If you review the current WordPress Agent Skills, there are plenty for coding functionality, but none that just help you get custom designs into rigid confines of the block editor.
How do I design a custom hero section for WordPress? Use core blocks? Install a block library or pattern library? Write block styles, block variations, block patterns? Where do I put my custom CSS? There’s a sense of decision fatigue when it comes to design that slows down progress.
Core Content Modeling
EmDash includes data modeling capabilities, custom content types and custom fields, directly in its core. Of course, so does WordPress. With only a few lines of PHP, you can register post types and post meta, and WordPress does a great job of handling storage, API endpoints, and routing for you. And because these features have been around so long, AI is already really good at setting it up. It’s PHP, not JSON configs, but I think it’s pretty solid.
So it’s good, but there’s no UI-based management in WordPress, which they’ve included in EmDash (in a UI that will feel very similar to anyone with an ACF license key). This is why I think Astro will appeal to the Bricks and Etch crowd, the fans of “dynamic data” who want to use CPTs and ACF for every repeatable element. It feels very close to that workflow, close to Drupal and Statamic. On the flip side, if you’re skilled enough to Claude Code yourself an Astro site, do you need a UI for it?
EmDash also uses the custom database table approach, which I like, but I’m not someone who gets super worked up about the shortcomings of our post/post_meta tables. When plugins really need custom tables (like WooCommerce’s HPOS), they can do it, just with a bit more work. I doubt the majority of sites on EmDash would notice the difference if all their content was in the same table, but yes all the data typing stuff is very neat.
Content modeling in general is still considered a gap in WordPress, so there’s that. A few years back, I worked on a content modeling solution in collaboration with a team at WordPress.com (before I worked at Automattic), and while the solution we built didn’t really match the direction I was pulling for, it was an improvement and well-received. My biggest takeaway from that experience was that you don’t need to over-engineer or do anything fancy, just ship some decent field builders and iterate later.
I’m a fan of the block-bindings approach to metadata in the block editor, but I also think that not every type of content needs a visual block editor. Sometimes you just need a content type that has a bunch of fields, like a WooCommerce product, for example. We need a structured, block editor-friendly approach to building post types that are field-based. We need to blow open the editor experience and stop expecting every field to fit into one tiny sidebar.
Takeaway for WordPress: We should really have a UI for content modeling in core built on top of a robust Fields API. I refuse to believe that it’s a hard problem to solve- the plumbing is already there, the visual components are already there, it just requires prioritization and a commitment to a user interface (easy for me to say from the sidelines). Even if ACF is overkill, plugins like CPT UI prove you can do it with a very light touch.
Speed of Development
Cloudflare is known for the rate at which they push new features out. Often they’re just throwing stuff at the wall to see what sticks. That’s great. We don’t know how long they’ve been working on this, but it’s pretty far along. Feels a bit vibe-coded, but it is built on the already-popular Astro framework. And it shipped, which is what really matters. WordPress, on the other hand, is a massive, trusted platform already and it makes sense that feature development is more measured.
But I want to talk about the development speed of building with it. Getting from zero to a basic design is fast. I mean, really fast. Part of that is the headless-style architecture and front-end freedom I mentioned above. On top of that, the install comes with Claude Skills that include opinionated approaches to using their CLI and plugin architecture.
The platform allows for incredibly fast project spin-ups. What I’m wondering is how the maintenance workflows will go. What happens when a critical security update goes out in core or one of your plugins, can you just hit “update” on production like WordPress, or do you need a developer to patch and test the upgrade locally first? How will those issues be communicated to the platform’s users?
This also gets to the core of their comparison with WordPress: plugin security. The platform has a much more locked-down approach to extensibility that’s inherently tied to Cloudflare’s services. The docs also hint at a future plugin marketplace with security auditing.
The framing they provide is that WordPress plugins are insecure by default because they are just executable PHP. A plugin can literally destroy or expose your entire database if it wanted to. This is very true, but it also has meant quite an expansive amount of freedom in what you can do with WordPress. Will EmDash have the same level of extensibility?
I want to see an “events calendar” plugin for EmDash. Events calendars are the worst. You have dates and times, dynamic content that disappears on a schedule. Single posts that might represent multiple dates with weird recurrence rules. A front-end calendar that has to match your design and offer multiple calendar views. Ticketing and transactions. It’s a common use-case, but it’s a pain to make. What will something like that feel like in EmDash? Will it integrate with other popular plugins? An events calendar is not a one-shot feature.
Ultimately, EmDash feels like a tool for agencies over end users. I’ve always argued that WordPress’ strength is in situations when we want non-technical folks to manage and collaborate on content. You don’t need a developer to launch a solid WordPress site (or to launch a terrible one!) But agencies have been a key ally in the growth of WordPress, and these other tools are making very competitive offerings.
Takeaways for WordPress We should absolutely be focusing more on developer experience in WordPress, especially now as even the least technical users now have access to LLMs that think and work like developers. WP CLI, Studio, MCP, and other tools are building a strong foundation, but there’s no single opinionated starting point and framework for WordPress development across the three major domains – data management, admin UI, frontend design. Decision fatigue and uncertainty, which are kryptonite to agentic coding.
WordPress has always been in a natural trade-off war between user experience and developer experience. The block editor is a great user experience, but can be a tougher developer experience. The site editor still has some user experience gaps, but is getting there. If I had to pick one focus, I’d start leaning towards developer experience for the next few releases, focusing specifically on the agentic workflows of content design and management (which overlaps with some user experience features like responsive design controls).
Final thoughts
I’m a Cloudflare fan, but I am concerned with how much they’re becoming a single point of failure and replacing the open web with hosted services. That’s natural, but concerning.
Open source doesn’t mean a single company can’t own the direction of the project, and it’ll be interested to see what the ultimate product vision is. In the spirit of open source, I wrote this post so that instead of arguing about intentions, we could learn from the positives.
There’s still some open questions. How easy will it be to collaborate on content and to extend the platform? If they’re starting from a version of classic WordPress, what vision do they have for the future? Will AI agents ever be reliable enough that even a non-technical person can fully own this type of project?
What do you think?
Other Takes (share yours!)
There’s a been a few other takes, and I’ll link to as many as I can, just comment below or find me on X.
Sharing a take here doesn’t imply I agree with it!
Cool but it lacks the major feature that makes WordPress work long term – community.
If only one company is contributing to a CMS how can you ensure viability?
Cloudflare did the next most obvious thing after acquiring Astro… they built a CMS for it. The post calls it the “spiritual successor of WordPress”.
But I have to ask… is the future really Astro + TinyMCE? Really?
How they narrowly scope plugins is excellent though.
For a certain kind of builder, this is cool! Expect to see plenty more of the industry coming after WordPress’s marketshare this year. We have work to do!
Also kind of funny to create a WP killer but also mimmic its long-dated and exhausted interface. Go big and reinvent it!
The open-source story needs clarity. It’s MIT-licensed, which is great. But it’s still a Cloudflare project, and developers will want to see long-term governance commitments before investing their time.
Open source and governance are nuanced topics. Celebrating and hoping for open governance from a publicly traded company is an amusing display of naivety.
The folks who are technical enough to use this are already doing that with Claude Code. They don’t need plugins … They can vibe code, learn things don’t always work, keep spending time .. or smart ones end up plugging a SaaS form builder, Shopify for eCom, etc because they are proven system of records.
Leave a Reply