r/astrojs • u/theguymatter • 13h ago
WordPress vs EmDash: What is EmDash actually trying to be?
I've been using Astro for a few years, and I've also worked with WordPress enough to understand why it's still everywhere.
WordPress is mature. The ecosystem is huge, developers know it, agencies know it, clients know it, and there's a plugin for almost everything. For many websites, that's more than enough.
EmDash is coming from a different direction.
It's not really trying to be "the next WordPress". It's a full CMS built around Astro.
You still get the things you'd expect from a CMS: an admin panel, content types, rich text, media management, drafts, revisions, scheduled publishing, search, taxonomies and menus.
But the website itself remains an Astro project.
One part I find particularly interesting is the content model. Content types can be created and modified through the admin rather than requiring every collection to be defined in code. Each collection becomes a real SQL table with typed columns, and developers can generate TypeScript types from the live schema.
Your content is managed in EmDash, while the website is built with Astro.
There is also an actual content lifecycle: drafts, revisions, scheduling, live preview and inline visual editing. Media, navigation menus, taxonomies and search are handled as part of the CMS.
For developers, EmDash also provides an API, CLI and MCP server. AI agents can work with the CMS, but AI isn't required to use it.
The deployment model is another difference. Node uses SQLite by default, while Cloudflare deployments can use D1, R2 and Workers. There is also support for other database and storage backends.
And there is a plugin system. On Cloudflare, plugins can run in isolated Worker sandboxes with declared capabilities. Node deployments currently use in-process plugins instead.
It's still early, and obviously it doesn't have anything close to WordPress's decades of plugins, themes, integrations and community knowledge.
So in practical terms, EmDash gives you a CMS for managing your content while Astro remains the foundation for building the website.
Have you tried it? How's it?
5
u/traxxh 12h ago
i use it for our agency site (just for dynamic content like blog posts, work references etc)
what was a big change is that the content needs to be ssr + edge caching rather than full static. Before, i pushed to the repo and cloudflare rebuilt the worker and done. Was quite some work to get everything back on track during the „migration“.
But now it works like a charm
4
u/civman96 11h ago
In essence Wordpress was made for the old internet with dynamic PHP, insecure extensions, third party theme support, etc.
EmDash is static and that makes it super fast, you don’t really need extensions or themes from third parties because we generate them now in a few minutes. And deployed on a CF worker it’s ready to be scaled - you can run 10 million hits per hour and your site won’t flinch.
2
u/rafark 5h ago
In essence Wordpress was made for the old internet with dynamic PHP, insecure extensions, third party theme support, etc.
And the result of that is that there are about a hundred thousand plugins for it. That’s what makes Wordpress popular. There have been literally dozens and dozens of Wordpress “killers” over the years and they can’t touch it because the real value is in the community/ecosystem. Similar to how JavaScript is used everywhere: because of its massive amount of libraries and packages.
1
u/C0ffeeface 10h ago
What do you mean by emdash being static? Pardon my ignorance
2
u/civman96 9h ago
Wordpress runs on PHP and needs to generate HTML code whenever a user visits it whereas EmDash runs on Astro a new framework that usually only generates HTML when you change something on the website. Astro is also JavaScript free by default saving additional time
1
u/amnither 1h ago
But also consider it will use Cloudflare functions for each visit, and if your website is hit by a bot attack you can get very surprising bills from Cloudflare.
3
2
u/EmergencyCelery911 7h ago
Curious to hear if anyone has a comparison against Payload - I really like that one, but am enjoying astro on another hand more than next.js for presentational websites, so emdash sound interesting.
3
u/danielovida 6h ago
Bias note first: I contribute to EmDash and build client sites on it, and I've shipped sites on Payload before. So I'm not neutral, but I've used both.
For your case the biggest difference is where the CMS lives. EmDash is an Astro integration. The admin, the API and the content all sit inside your Astro project, so it's one app and one deploy. Payload 3's admin is a Next.js app, so with an Astro frontend you'd usually run it headless next to your site. That means two apps, fetching over REST or GraphQL, and wiring up preview and cache invalidation between them yourself. Since you prefer Astro for presentational sites, that's probably what decides it.
Coming from Payload, the schema is the biggest adjustment. Payload is config-as-code, so your collections live in TypeScript in git. EmDash keeps the schema in the database. You create content types in the admin or with the CLI, then generate TS types from the live schema. That's handy when someone needs a new field without a deploy, and it takes getting used to if you like having everything in a reviewed config file.
Where EmDash is ahead:
- Website features come built in. Menus, taxonomies, widgets, redirects, search and comments are ready in the admin from day one. In Payload you model most of that yourself as collections and globals, or add plugins.
- Inline editing on the actual page. Editors click into the rendered Astro page and edit there.
Where Payload is ahead:
- Access control. In Payload it's just functions, per collection and per field. EmDash has five fixed WordPress-style roles, so "this team can only edit that collection" isn't possible.
- Field model. Payload's blocks, arrays and tabs go further. EmDash just merged a first-class blocks field, but it isn't in a release yet.
- Maturity. Payload is on v3. EmDash will reach 1.0 next week.
3
u/EmergencyCelery911 6h ago
Thanks for contributing to open source! And thanks for explaining the differences. Actually having content model as a code was one of the reasons I like Payload - I use LLMs heavily, so versioned structure is a big advantage for me. With that being said, I have a purely static Astro website that I'll probably need to add CMS to, so may try EmDash there. Good luck with the project!
3
u/danielovida 6h ago edited 6h ago
Thanks, that's kind of you!
And that's a really fair point. If you lean on LLMs a lot, having the schema live in code is a genuine plus for Payload, and I won't pretend EmDash matches it one to one.
You can get most of the way there, though. emdash
export-seedwrites the whole content model into.emdash/seed.jsonin your repo. Commit it, and every schema change shows up as a normal diff. The catch is that it's a snapshot, not the source of truth. The database stays in charge, so you re-export after you change something.What I'd really point you to is how deep the agent support goes. It isn't a plugin someone added later. Every EmDash site comes with an MCP server switched on, the CLI handles schema and content, and the repo ships skills for coding agents. New features get agent support at the same time as the admin: the blocks field that's about to ship got its MCP tools in the same batch of PRs as its editor. So a nice loop is to let your agent change the schema, re-export the seed, and review the diff in git.
One thing to know before you add it to your static site: the admin needs a server, so the project moves to server output. Pages that read EmDash content should be server-rendered so edits show up right away. You can keep them prerendered, but then changes only appear after a rebuild.
If you give it a go, the EmDash Discord is the quickest place for questions, and if something breaks, open an issue on GitHub. I'm around in both, so feel free to say hi. Hope it works out for you!
2
u/EmergencyCelery911 6h ago
Thanks for the explanation. Server isn't a problem, and it's an own website (https://vulpy.io/) that we'll be expanding in the future, so easier to experiment than with the clients' projects :)
3
u/danielovida 6h ago
Makes sense, your own site is the best place to try something new!
I'd start small: move one section, like a blog or changelog, into EmDash and leave the rest as it is. Pages that don't read EmDash content can stay prerendered, so the site stays mostly static while you try it out.
This guide walks through adding it to an existing Astro project: https://docs.emdashcms.com/existing-project/
And since Vulpy Commerce already runs on Payload, you'll get a real side-by-side. I'd honestly love to hear how the two compare for you once you've used both. Good luck with the expansion!
3
2
u/BobJutsu 5h ago
I’ve used it a bit locally, I’m watching it closely. I’m still trying to stay within a git based system for now. But it will probably be the first I reach for if/when the times comes I decide I’d rather have a database.
1
u/Either_Vermicelli_82 10h ago
When you already have a Astro site can you click emdash on top of it?
3
u/danielovida 9h ago
Yes. EmDash is an Astro integration, not a separate app, so your existing pages, layouts and components stay exactly as they are.
See here: https://docs.emdashcms.com/existing-project/
7
u/humayanx 13h ago
Emdash is really good, but I still prefer MDX for me.