The Deploy to Cloudflare button in the article is not working for me.
It takes me to the expected Cloudflare dashboard page, with title “Clone a repository” and with the GitHub repository URL field filled with https://github.com/emdash-cms/templates/tree/main/blog-cloud... but when I click Continue, the Continue button changes to “…” and animates indicating it’s thinking, but then nothing happens. No error messages shown, nothing. The Continue button switches back to having the Continue text and being clickable.
I tried deleting a couple of old applications I had in the Workers & Pages page of the Cloudflare dashboard thinking that maybe I had exhausted the number of such applications I can have on a free Cloudflare account. The number of applications I have is now down to 7, after deleting a couple of old ones. Still, attempting to deploy EmDash to my Cloudflare account fails in the same way as before without any error messages shown.
I was using Safari on iOS 18.7.1. I will try on a desktop browser, in case the problem is only happening in Safari on iOS.
So this product has nothing to do with wordpress, it's just another CMS that mentioned WP only bcz they created a migration plugin that won't work on 90% of existing wp sites and won't work on 100% of woocommerce sites.
This is no successor, it's not even in the same universe.
- vendor lock-in, losing gpl, losing access to plugins source code, loosing ownership.
yeah it's strange, if you are building a CMS in AI times, I think you would want an llm integration first. Not a UX clone of WordPress. The UX of WP is sort of a historical clutch not a plus.
I'd go the other way. Have less stuff. Just a text box, markdown, insane support for mermaid and everything. Dump the "blocks" of wordpress etc. Too confusing and fiddly. Maybe have AI assist to help with styling the rendered page a bit.
> Our name for this new CMS is EmDash. We think of it as the spiritual successor to WordPress. It’s written entirely in TypeScript. It is serverless, but you can run it on your own hardware or any platform you choose. Plugins are securely sandboxed and can run in their own isolate, via Dynamic Workers, solving the fundamental security problem with the WordPress plugin architecture. And under the hood, EmDash is powered by Astro, the fastest web framework for content-driven websites.
To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites.
But of course, then they wouldn't be able to sell their own "workers" product, so suddenly I think I might understand why they built it the way they built it, at the very least to dogfood their own stuff.
I'm not sure it actually solves the "fundamental security problem" in actuality though, but I guess that remains to be seen.
I love building static (or statically generated) websites, but all too often, customers want dynamic content. And what's worse, they don't tell you up-front, because they don't really understand the difference.
"I need a website for my bakery". "What's supposed to be on it?" "Our address, opening times, a few pictures". I build them a static website.
"Now I need a contact form". Ok, that doesn't really fit into a static website, but I can hack something together. "Now I need to show inventory, and allow customers to pre-order". A static website won't cut it anymore.
When you develop for clients, especially those that you don't know very well, it's a bad idea to back yourself into a corner that's not very extensible. So from that perspective, I really get why they give plugins such a central spot.
This is the main reason why WordPress is so popular still to this day. You can cache the crap out of the frontend to the point that it’s basically a static site at that point but then it’s still all running on top of a dynamic platform if you need that flexibility in the future.
I got my start in webdev slinging WordPress sites like a lot of self taught devs and I definitely see the pain points now that I’ve moved on to more “engineering” focused development paradigms but the value proposition of WP has always been clear and present.
Given how WP leadership is all over the place at the moment, I can see how Cloudflare sees this as an opportunity to come in and peel away some market share when they can convince these current WP devs to adopt a little AI help and write applications for their platform instead.
This is the most underrated point about CMS choice. The cost of migrating from static to dynamic is way higher than starting with a dynamic platform and caching aggressively. WordPress won precisely because you could start with a $5 blog and end up with a full e-commerce site without a rewrite. The question is whether EmDash can match that upgrade path while actually keeping the security promises
> To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites.
To me this wording is strange, since traditional web frameworks do render pages server-side. The specific functions of their templating engines are often even called "render" (https://jinja.palletsprojects.com/en/stable/api/#jinja2.Temp...) or "render_template" or similar (https://docs.djangoproject.com/en/6.0/topics/templates/#djan...). I guess "server-side rendered" is being coopted by the JS ecosystem for some time now, as if they had come up with the very idea of rendering pages on the server side.
It would do the world some good, if people could just look at a technical term, understand its meaning by its components, and then not go: "Ah yes, I will use the same term, but no, no, no, I mean something different by that!"
For this example:
(1) "server-side": happening on the server
(2) "rendering pages": various meanings in different contexts, but on the web meaning filling in information and creating parts of the HTML tree, to get a full HTML document.
This has been done for decades and the result are usually, for the browser, static web pages. Static as in the opposite of dynamic. Dynamic meaning that the pages react to user interaction, meaning scripting, meaning JS.
I think this is true, however, when it comes to non-coding clients I've worked with they really do like the ability to make minor edits to a site with a UI rather than having to continually ping a developer.
The problem with WordPress (and it looks like this solution largely just replicated the problem) is that it's way too cumbersome and bloated.
It really is unlike any modern UI for really any SaaS or software in general.
It's filled with meaningless admin notices, the sidebar is 5 miles long and about 98% of what the user sees is meaningless to them.
Creating a very lightweight, minimal UI for the client to edit exactly what they need or like you said, just static files really is the best solution in most cases. The "page builders" always just turn into a nightmare the clients end up handing over for a dev to "fix" anyways.
Not sure why so many people feel the need to continue on the decades of bloat and cruft WordPress has accumulated, even if it's "modernized."
There are two types of WordPress sites from my perspective as someone who got their start in webdev in that ecosystem.
The first and arguably largest is exactly what you describe. Little sites for small businesses who just want an online presence and maybe to facilitate some light duty business development with a small webshop or forum. These sites are done by fly by night marketers who are also hawking SEO optimization and ads on Facebook and they’ll host your site for the low low price of $100/mo while dodging your phone calls when the godaddy $5/mo plan they are actually hosting your site on shits the bed.
The second, and more influential group of WordPress users, are very large organizations who publish a lot of content and need something that is flexible, reasonably scalable and cheap to hire developers for. Universities love WP because they can setup multisite and give every student in every class a website with some basic plugins and then it’s handsoff. Go look at the logo list for WordPress VIP to see what media organizations are powered by WP. Legit newsrooms run on mostly stock WP backends but with their own designers and some custom publishing workflows.
These two market segments are so far apart though that it creates a lot of division and friction from lots of different angles. Do you cater to the small businesses and just accept that they’ll outgrow the platform someday? Or do you build stuff that makes the big publishers happy because the pay for most of the engineering talent working on the open source project more generally? And all that while maintaining backwards compatibility and somewhat trying to keep up with modern-ish practices (they did adopt React after all).
WordPress is weird and in no way a monoculture is what I guess I’m trying to say.
4) Don't use a stack of plugins, if you must use any keep them as dumb as possible and stick to those with a longstanding reputation.
A basic instance, set to auto-update, installed on a shared webhost where OS/web server updates are someone else's problem is pretty foolproof. A VPS running a long-term distro set to auto update is almost as good.
---
That said I personally dropped Wordpress for static site generation years ago because I realized I didn't actually need any of the dynamic features and wasn't using the WYSIWYG editor. Now I write Markdown in to a file in a git repo and then trigger a regeneration whenever I update it.
I wrote my own CMS, as the core WordPress functionality wasn't too much to replicate.
But eventually the WordPress ecosystem was too strong, and the real value proposition was plugins and familiarity. That continues to be true to this day, which is why no CMS has de-throned WordPress in spite of significantly better UX, architecture and developer experience. None of it matters when the client has a suite of plugins they have been using for 10+ years, that are now core to their business.
If it uses Astro, then it's a literal static website generator. But with modern React components if you need anything on top of this. The same with plugins, I assume people don't have to use those but the important thing is that you can if you want to.
Distribution of the content as static html or in any other format is a very tiny aspect of managing content and mostly a solved problem for any CMS nowadays. Focusing on that minimal aspect seems grotesque as there are much bigger challenges in making potentially large amounts of content actually manageable by a potentially very heterogeneous group of content creators with varying skills, responsibilities and relationships.
But "back to CMS roots" is absolutely not what the WordPress ecosystem is about. It's about the absolute galaxy of plugins that provide you with an entire digital experience "in a box". You can just install whatever plugins for ecommerce, CRM, forms management, payments, event calendars. They will all plugin to both the template system and the MySQL database. There are a lot of well-known and reputable plugins with huge installed bases (woocommerce, gravity forms, yoast seo) but there's a ton of shady ones that can infect your install. Cloudflare is directly addressing the shortcomings of the existing plugin architecture indicating they intend for EmDash to fill a similar niche as an All-in-One digital experience and not just a simple CMS.
The question is then they'd be building some brand new thing not compatible with wordpress. Supposedly the proposition is to steal people away from wordpress. Not just get people building something from scratch looking for a new framework. I'm guessing the recent lawsuits also provide some momentum.
It's not compatible with WordPress, though. It slurps a WordPress export, which is quite literally static data. They expect you to code up anything dynamic using their agent skill.
You either write them by hand, or use a tool that generates it locally, upload everything and you're done. Perfect security. Great performances.
It's in this sense that static generators go back to the source, the simply produce dumb HTML files that you upload/publish to a web server that doesn't need to run any code. Just serve files.
Imho CMS is just a tool that generates static html files on the server. The distinction is a bit artificial. CMSes have static html cashing and CDNs will allow you to "one-click" firewall the dynamic administration and cache the static html for you.
Static website generators are cool way for programmers to do that work on their machine but in the end the distinction of what gets served is very small (if you set up the basics).
CMSs allow non-technical people to update the site - that's why WordPress, Drupal, and all of the shambling corpses of "digital experience platforms" still command the dollars and eyeballs that they do.
Go ahead and give your content people access to a static site builder and see how quickly the process falls apart. Static site generators are perfect for engineers but terrible for the marketing people that are the actual "customers" of your public-facing website.
I used Hugo, told the marketing people to send me a markdown file and I'd load it up to Hugo. That was clearly too painful for them. So I told them to send me a Word doc and I'd convert it to markdown and load it up. That was too painful. I told them to send me an email with the words and images and I'd work out the rest. That was too painful.
They got some marketing agency to rewrite the entire marketing site in Wordpress, and then we had to implement some godawful kludges to get our backend to redirect to their shitty WP host for the appropriate pages. It was awful.
But the marketing folks were finally happy. They could write a blog post (that no-one read) themselves in the actual CMS and see it go live when they pushed the button.
We spent thousands, in a cash-strapped startup, dealing with this bullshit.
Reminds me of Vercel and NextJS, where a popular framework design is constrained by, or optimally runs, on their infra, but then comes with pains or unusualness if self-hosted (eg. middleware). Vendor lock-in plays are a big red flag
It looks like they rolled it so you can plug in local components of your choice, though? The security model does assume you have MAC containerized environments available at your fingertips though, so having something like DHH's once is probably a soft minimal dependency if you want to do-it-yourself.
This is very interesting. I've worked with WordPress on and off for 10 years, and I'm convinced that this project has got 2 things absolutely spot on. TypeScript and Worker plugins.
I've given the security, or lack of, WP a lot of thought recently. In WP malicious plugin has access to the database, enfironment variables, rendering text on screen (think XSS). Luckily, a thoughtfully designed plugin system can mitigate all of those issues.
I've been working on a headless CMS in my spare time that is eirily similar to EmDash in a few ways. It's in very early development, but I will share regardless. It's called HotsauceCMS - https://github.com/hotsauce-team/hotsauce
- I went with optional NodeJS or Deno Worker plugins, this means that first-party plugins can benefit from the speed of in-process, and other plugins can be run in Workers. For fine grained permission control, you can use Deno Workers.
- I went with absolute minimal dependencies, I am so fed up with Dependabot alerts and npm supply chain hacks. My CMS has only 4 dependencies, 0 transistive dependencies.
- It's Drizzle schema first, and headless. So you have full controll of the database structure, use cms hints in your schema for features like file upload.
- It's database-agnostic, so it works with any Drizzle-supported database (Postgres, MySQL, SQLite)
- Being headless, you can use any frontend, my preference is JSX w/o react, but anything goes.
Feedback is absolutely welcomed on HotsauceCMS, did I miss a trick, am I on the right track?
Anyway, congratulations on EmDash. I'll be following closely, excited to see how the next few months unfold.
I personally i am in the other camp and think they got the language change absolutley wrong. I already have php installed on my server why do i need to install TypeScript? The easiest website to run is in php. All other languages add a barrier.
I agree with your sentiment. Meet the customer where they are at, right?
Years ago, I would have said small bussinesses are on cPanel, FTP-ing files to the server. Asking them to run NodeJS is crazy. But here we are, the hosting landscape is vastly different, is it still so crazy to ask a small business owner to put there code on GH, connect GH to a hosting platform and push?
---
Anyway, I doubt you will see people dropping off WP and migrating sites to EmDash. What's more likely will be that it is considered as an alternatave for new projects.
- I've been done GraphQL server with a build step to share types between languages.
- I've used untyped JS client side code.
Both are prone to bugs, and not much fun.
TS for front and back end: sharing types means you'll have editor type hints, catch type errors at lint (or build), and you might even share validation logic between client and browser.
I used to work with Wordpress a lot, but last time was a couple years ago.
The appeal for the company i was working with was ease of installation on legacy servers (FTP). You would just upload the files, and it worked. No CLI tools, no dependency management, no build tools.
But yeah, security was a big issue. Constant hacks.
The constant hacks are side effect of Wordpress popularity. Every discovered security flaw is exploited by bots almost immediately. Unless you keep up with the updates you are very vulnerable.
It is not because wordpress is built on "legacy" stack. Other CMSes on that stack (and many are very popular) don't have this problem.
The popularity helps, but it’s also because WordPress’s security model is distilled insanity. PHP makes this insanity far easier than most languages, and WordPress embraces that, whereas the likes of Drupal rebuff it.
I think the security issue is that people trust random plugins without reviewing them.
I’ve been running WP with small and large companies and no big security issues. You either build your own plugins or go with the trusted few you need to augment your operation.
Same. I've been working with and managing thousands of WP sites for over a decade and the only issues I've had have been with sites acquired from 3rd parties with random themes and plugins (and old WP versions) that break if you update something. Those have gotten hacked and have caused many headaches.
Basically no issues with sites built in-house. As you say, only reputable 3rd party plugins (like for SEO, caching, multilang) most others made in-house.
> I am now scared to talk to anyone. Eventually the conversation turns to AI and they want to talk or show their vibecoded app.
> I am just tired boss. I am not going to look at your app.
Hey, I feel bad for you. I would say try and avoind HN if you don't want to see AI.
But, in this case, I want to respectfully disagree with you. I read the frontpage of HN almost daily, I never really jump into conversations, for this post about EmDash I am absolutely qualified to contribute.
There are precisely 2 open source projects in existence (proove me wrong) where the "Worker Plugin" architecture has been taken. Mine and EmDash. Looking at some of the code examples from EmDash was like looking at my own docs.
If you don't want to look at my app, then fine. But please don't gatekeep, I'm qualified to talk here.
I run a handful of WordPress sites. The plugin problem is real. I've spent more time managing plugin updates, conflicts, and security patches than actually building content for the sites.
But the reason I'm still on WordPress isn't loyalty. It's that my clients can maintain their own sites without me. A small business owner updates their own pages, adds blog posts, changes a phone number. No developer needed. That's not a feature of WordPress. That IS the product.
EmDash solves a developer problem (sandboxed plugins, TypeScript, Workers) by building a developer product. Nothing wrong with that. But calling it a WordPress successor misses why WordPress won in the first place. It wasn't the code quality. It was the guy who runs a bakery being able to edit his own website on a Sunday morning.
In my opinion, Cloudflare are coming at this from the wrong angle. WordPress is so popular because back in the day it was the easiest way to get a website built. So it got a network effect of engineers behind it which is why it persists at 40% of websites today. Same thing happened with React - majority of Typescript sites are written in React and NextJS because of the network effect around it.
Yeah the security aspect is important, but how many of those Wordpress engineers are going to jump ship to this because of security when they've been fine with the risk so far? My money is not a lot. If someone is a WordPress dev in 2026, they're probably not the type of dev that likes to upskill and learn new tech. Similarly, if you're looking to target the average joe looking to build a fresh website, would that consumer really choose this over Wix or Squarespace? It doesn't look easier to use so I wouldn't count on it. So where is the network effect going to come from to make this the new WordPress?
I could see Vinext being successful if they keep at it— I think there are a sizeable amount of people who would like to move away from Vercel (and who will probably migrate to Tanstack when the ecosystem is more stable). But I'm not sure people on WordPress really want to leave. If they really want to make this successful I think they need a better angle which in my opinion would be making it easier, quicker, cheaper and more flexible than Squarespace/Wix/Shopify etc
The "WordPress devs don't like to upskill" framing is off. Most of them maintain sites for clients who need WordPress specifically. They stay because their clients stay, not because they can't learn TypeScript.
The real talent drain isn't about technology at all. It's the governance mess. The WP Engine lawsuit, Matt's behavior on community Slack, the constant drama. That's what's pushing people out.
But even with all of that, nobody's leaving for EmDash. They're leaving for freelance Webflow work or getting out of CMS entirely. Cloudflare would need to solve the "why should I rebuild my entire business on your platform" question before the talent pool argument matters.
> A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations.
Someone should introduce the authors to the lovely em dash character. It's perfect for such sentences!
I can't help but sense a level of arrogance when they launch their product by writing an obituary for a competitor. Is this what people feel when they make fun of the "(product here) killer"?
We have a cursor subscription and work and i now see many non-technical people building their own internal tooling. People that had essentially never written a line of code before this new revolution.
The cost of building software has really drastically decreased.
> x402 is an open, neutral standard for Internet-native payments. It lets anyone on the Internet easily charge, and any client pay on-demand, on a pay-per-use basis. A client, such as an agent, sends a HTTP request and receives a HTTP 402 Payment Required status code. In response, the client pays for access on-demand, and the server can let the client through to the requested content.
Fascinating. Cloudflare is envisioning a future where agents are given debit cards by their owners, so they can autonomously send microtransactions to website owners to scrape content or possibly purchase goods on the owner's behalf. I don't know how I feel about that but there's no doubt it's a fascinating concept.
Brb, setting up a honeypot that always responds with HTTP 402 Payment Required demanding 10cents per visit... That's the next "selling 1 million pixels on my website for $1 each", I guess
If you can find a way to trick agents into always accepting your payment required then you could set up a tarpit generating trash content or an infinite string of redirects or "read this other page for more info", charging extra for each one.
To be frank, I thought this was an elaborate April Fool's joke, particularly when I saw that. It suggested to me 'you could charge for anything' while subtly implying you should also be paying them (within a handy deploy button every few paragraphs) for the privilege of running their stuff on their hosting solution.
Oh dont worry, I'll do the feelings for the both of us, I have over a decade of experience feeling smugly and validatingly superior to people who save payment info on ipads and then hand it to their kids.
Welp, it looks like if you selfhost, the sandboxing of plugins benefit goes out thr window from what I'm reading. What kind of open source is that? Opencore? More like openinsecure, for thr security version, pay the Piper. I might still give it a try, but I sure hope we can put monthly monetary ceiling, had ceilings on our accounts. Anyone knows if cost-caps are possible on CLOUDFLARE??
Also, it looks like there are egress charges to download R2 object storage. So he day we choose to exit stage left, we will be taxed. Wanna setup independent backups for compliance, we will get taxed on egress. Am I reading this right guys??
Honestly, you'll struggle to find a cloud platform cheaper than cloudflare.
The $5/mo gets you 10 million dynamic requests (static assets are not included in this limit, so often a single pageview will be 1 dynamic request) and that would be across the whole workers product for your account, no extra pricing for extra websites, domains, or anything else like you'd see in most "wordpress hosting"
I run all my personal sites and client sites (one of them for a fortune 500 company) in the $5/mo plan, and the only time I went over that was when a client got hammered with malicious requests (and it was like $100)
Disclaimer: I have no relationship to cloudflare, I'm just a happy customer
I run a rust webserver on a €4 VPS from hetzner that serves 300M (million) requests a day. Way cheaper than doing that on _any_ "serverless" request-based platform, I think.
Yes perhaps I should have specified you can't get much cheaper for serverless platforms.
You can certainly run a VPS like that for cheaper, you could probably even beat the raw request numbers from those 1€ a month vps from ovh or similar. The key difference is with cloudflare your site is globally distributed by default, and you get to buy into the whole ecosystem, if you want.
But sometimes you do have clients in both sides of the atlantic and it's nice being able to cut their request times by a few hundred ms "for free". Personally, that's not the main reason I use cloudflare, but it can be handy!
I don't think it's the code that makes WordPress valuable. I've been learning WordPress recently and haven't been too impressed with the internals. WordPress is valuable because of the ecosystem and support. I have no doubt that WordPress will still be a thing in ten years. What's the support plan for EmDash? I see commits are mostly from a single developer.
E: Oh, I think it's an April fools joke, I'm embarrassed.
Cloudflare doesn't do April fools jokes. In fact, 1.1.1.1 was released on April 1st back in 2018 and now it's one of the most used DNS service in the world.
A little larger, a lot of the time, though I like a small initial commit better. Though just a little larger. Not so large that it is too large to show on a GitHub page. That means not using version control properly.
Usually when someone decides to share code with the world, they don't want to publish the actual development history. They publish the first version that is ready to go public as the first commit. With enough functionality etc.
> Not so large that it is too large to show on a GitHub page.
Maybe not applicable in this case, but Github has a ridiculously low threshold for when it starts hiding diffs. Probably a limitation of their new React frontend.
I hated that shit. I'd load Slashdot and there was no real content or it was difficult to find real news amongst all the crap. It's not funny. It's annoying.
Some of the april fools things can be annoying, but I have a big shrug for there being less real news for a day. Anything important will get through and most days don't have much interesting news anyway.
Would you be annoyed if HN went offline just for the hell of it for a day every year?
But you're right, I was an extremely angry person back then. Many years of therapy and deliberate ongoing work and I'm a radically different man. Thank goodness I got to the other side.
There were some years in the 90s and early 2ks that had good april fool's jokes, and that was what bubbled up. Not everyone did, so the novelty also made the "meh" ones seem better. By 2008ish everyone was doing one, and most of them weren't very good. By 2012ish marketing got involved and almost all of them were terrible and unfunny.
It was a nice tradition but, like many things, the scene got too big and corporate. It was a zombie tradition for a while then slowly faded away.
In fact when cloudflare started releasing serious things on 4/1, I found it to be a refreshing subversion of the trope.
I think you need to account for the base rate. There's a lot of WordPress plugin vulnerability disclosures because there's a lot of WordPress plugins and there are enough deployments of the plugins to make searching for those vulnerabilities is worthwhile.
That site warns that WordPress plugins can be abandoned, but that's clearly not a WordPress specific issue. Sure some site could use SSG, but that's a different design.
I certainly don't want to claim WordPress security is good, but I'm not sure that site is measuring anything meaningful.
Its impressive work from CF that lots of people in this thread are unsure whether its a joke or not, like a delicately balanced april fools for the hn crowd
wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
yes you want a global db handle sure ya lets delete all tables woohoo
If it powers 30-50% of the web, including thousands of major websites, it works at some level.
Ivory tower "just don't use a low-cost solution" people aren't going to hand over money to people to use a higher-cost one, are they?
And ignoring why it's used besides the sloppiness means they have a huge blind spot to what people actually want:
"wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious"
Nothing in this quote doesn't describe very real needs.
> wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
You've sort of nailed it, but this isn't a bad thing. An alternative for these customers does not exist.
There's another vertical which is organizations that have armies of writers churning out content. Any kind of publisher or advertiser, basically. There is no better CMS for this. Large organizations like NYT, etc chose to write their own.
>> wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
> You've sort of nailed it, but this isn't a bad thing. An alternative for these customers does not exist.
Yes! I'm locked into WordPress, which I hate, because it's the only platform that will allow a non-developer to maintain it if I get hit by a bus.
I started building sites for clients in the late '90's, and quickly made "client can edit their phone number on all pages" a key requirement. Wordpress with a WYSIWYG page builder solves that — it's not the only solution, but it works pretty close to right out of the box.
A decade ago I had to learn and run WordPress for a job. I held my nose up the stink was so bad. But quickly I learned how to manage it and have modern sensible practices around it and I've probably gotten more real value out of it than any other CMS or web framework I've touched. That includes Rails.
Thankfully I don't have to do that anymore, but you can sanely and safely run WordPress today and there's zero shame in it.
There are options that can be run by anyone, but they're often very constrained in what they can do and show.
Wordpress is solidly in that middle ground where you can do a large amount of customization if someone'll pay for it, and then they can do the day-to-day care and feeding of it.
Everything else has either been much worse in all possible ways (Joomla!) or has been a collection of developer wish-lists unusable by anyone (Drupal).
yep. we like it because with shopify or other platforms, you run into limitations. with Wordpress I can literally just whip it into whatever shape i want.
As a (unfortunately) wordpress dev this seems to solve my single biggest painpoint with WP. Which isn't plugin security, but the overall plugin architecture.
WP treats plugins as content, literally in the same top level `wp-content` directory as uploaded images. This makes CI/CD among other things, a nightmare. But EmDash plugins are just TS modules, which has got to make things easier even if plugin configuration does end up in the db somewhere.
Wordpress has no concept of a "staging site" and no way to make changed and then "export" them from dev to production; you basically have to either restore it as a backup or just replay the changes by hand.
I’m not the one you asked, but when I did WP work a few years ago I would solve it via a hook that was triggered on Jenkins deploy. The hook would always fire and listeners to that hook would execute migration scripts and similar callbacks. For example used it to migrate some tags to categories and vice versa.
Serious question: Why is everyone still using JavaScript to AI-code projects? You can vibe-code apps with real languages now.
There's no reason to use an interpreted, bloated, weird language anymore. The only reason interpreted languages were a thing was so you could edit a file and re-run it immediately without a compile step. Compiling is now cheap, and you don't have to build expertise in a new language anymore. Ask AI to write your app in Go, it'll happily comply. Run it and it's faster with less memory use and disk space. The code is simpler and smaller making reviewing easier. Distribution is as easy as "copy the file".
I'll grant you, interpreted languages skip the "portability" compiling/distributing step, and let you avoid the stupid MacOS code signing. But Go is stupid easy to cross-compile, and (afaik?) the user can un-quarantine a self-signed app pretty easily.
there are loads and loads of reasons to use "interpreted" languages. that you can't think of even a single one while still pretending to be knowledgeable in the field is really intriguing.
> bloated, weird language
oh, i see, this is all just a religious rant. carry on!
Typescript is legitimately weird. You start off with Javascript, a language made to validate HTML forms. Then you implement a bytecode compiler so it's not unusably slow and buggy. Then you implement "frameworks" to try to make it create real applications across the insane platform that is the web browser. After twisting yourself into a pretzel just to avoid learning or making a new language, you finally invent another language on top of the first one just so you can have types. To top it all off, it takes up tons of memory and disk space. (I don't mention the slowness because I take it for granted, but 5x-10x slower than Go code is still worth considering)
i'm not a fan of ts either, but can see the appeal for business. of course it is bolted on ... like almost everything on the web, which is a complete frankenstein. but it works, and truth is there is no other alternative yet. otoh it is performant and efficient enough for almost anything these days.
coding in go (or whatever) and transpiling is just an extra step on top of that. not without benefits, mind! there are surely many situations where that is appropriate. but that still doesn't mean it is universally the "right thing". which brings me to:
> just to avoid learning or making a new language
there simply is no "one language to rule them all" nor there ought to be one. my entire career has been about learning different languages, techniques, tools, systems, environments and workflows. lots of them, nearly non stop. javascript has its nice place, and i like it vanilla, in all its weirdness and unapologetic untypedness. :)
Like it or not, it's the only language that'll cross over web backend, web frontend, iOS, Android, TV, Windows, Mac, et al. And with something like tRPC your data being fully end-to-end typesafe too.
The problem with Go specifically is that it's not great for processing arbitrary JSON and especially not your typical frontend code.
One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating.
Another problem is that the type system is often not expressive enough for frontend code. So you either have to generate types or end up with something like map[string]any, which is awkward and gives you less guarantees and support than what dynamic languages typically offer (in other words, dynamic languages are better at being dynamic languages than Go).
Now these problems don't emerge in every web UI based project, but when they do, it's really painful and limiting compared to what one is used to.
> One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating.
Wow that is the cheapest excuse I've heard recently. Templating languages can certainly be dogshit, but demanding it to be the native language is pretty weird. Also it's not like the JS ecosystem spawned their own weird abominations to do simple string concatenation. Sorry for being harsh, I understand that as a general inconvenience but attributing JS as superior is just bold.
I‘m not even a fan of JSX, but it’s simply way more productive than having a separate, idiosynchratic language for templating.
The issue is not an aside or secondary. Web development is a highly competitive profession. I literally cannot afford too much development friction.
There are very strong alternatives to JSX that I prefer btw.
Lit-html builds on JS native template literals, the performance and bundle size is astronomically better.
PHP I wouldn’t recommend anyone, because of the insane footguns, and in recent years it has become increasingly unstable, but if you already know it well, then it has a lot of properties that are missed in other ecosystems.
Clojure does it best from a productivity standpoint if you own the whole stack. The REPL workflow is far ahead of anything else I tried and expressing UI as regular, compact data literals is a unique advantage.
Now I like Go, and I tried it for web development, because I consider it a very high trust language and ecosystem. It just has a few disadvantages in that department when used in the trenches.
Yeah, my theory is that Rust is going to be a somewhat "local optima" for a while for LLMs.
LLMs have a couple major problem, they hallucinate and make mistakes. So the ideal way to use them is to constrain them as much as possible with formal methods. Rust's type system is a formal proof of some forms of correctness, this will let "vibe-coding" work to a much higher degree than with other languages.
In the very long run, I suspect that all vibe-coding will actually occur in a language with dependent types and we'll push as much as possible into being proven correct at compile-time. Since the cost of generating code is plummeting, and thus the sheer volume of code will be exponentially rising, this is the only way to prevent an unsurmountable mountain of errors.
Formal methods and LLMs are a match made in heaven.
Most coders are familiar with javascript. Javascript has the largest community. If you want to be popular, then JS or rather TS it is.
But it's correct that it is odd. As long the lang is mainstream enough, it hardly matters. My assumption is that JS/TS coders have the highest resistance to switch platforms, the ecosystem is huge, it's cross BE/FE, performance isn't complete trash, everyone they know knows the platform as well. Why switch? It's a screwdriver, if your passion is to screw things, you will.
Do LLM's not benefit from the abstractions higher level languages like Javascript/node offer?
Perhaps I'm speaking out of depth because I haven't done a lot of Golang, but I've always thought of it as a systems language first, which means by necessity you have you to handle lower level problems yourself. I'm sure there's plenty of libraries that paper over this - but the philosophy of the languages themselves is different. Javascript was designed to solve CRUD like interfaces/problems quite well.
Maybe this is just an outdated argument though that isn't really relevant with modern golang/rust though.
You can implement apps in any popular language you want with modern LLMs (they still need to be trained on that language). Tell it what to write and it'll do it. But the downside is, if the language is a memory hog or takes up tons of disk space, you're not gaining anything. If you don't have to manually write the code yourself, you might as well pick a language that has the fewest problems when executed.
Go has a really solid standard library which removes a lot of what you'd typically implement separately. You don't solve lower level problems because the language already solved it. Nodejs has the opposite issue, where there's virtually nothing standard, so people made libraries to implement 5 lines of code. Rust also has a minimal standard library, and is more complex than Go. If you want a dead-simple, batteries-included compiled programming language, Go is pretty much it. Since you write less code with Go, there's less context use, so actually, the LLM has an easier time with Go apps.
It started as a 'systems language' but it has many projects that extend its usefulness. There are two separate frameworks that let you write one Go app and compile it as an Android app, iOS app, Mac app, Windows app, Linux app, both GUI and console. It has multiple web frameworks, and one is even an Electron replacement. The thing it doesn't have is a REPL.
A WordPress spiritual successor backed by Cloudflare sounds great in theory, but the headline feature, plugin isolation via Dynamic Workers, only works on Cloudflare's runtime. On any other host it's just a TypeScript CMS without the security model that justifies its existence. Open source but architecturally locked in.
I missed this. So they didn’t really solve much at all. I guess at least it’s compatible with other runtimes. But yeah, who would’ve guessed that Cloudflare software would (besides being vibeslop) prefer Cloudflare infra. This, of course, makes the software quite hard to adopt.
Are you saying that by providing a globally available service, they're engaging in vendor lock-in, because otherwise you'd have to build your own globally available and distributed service...? ...yeah?
But if you wanted to run Workerd on EC2 or Google Cloud or whatever, you could...so not really sure how that applies here.
You cannot say you’re the spiritual successor to WordPress, if your software doesn’t support running plugins out of the box on arbitrary installs. WordPress is very easy to host and scale, you only need a basic server and a CDN. A spiritual successor would follow that and also have all the new shiny stuff.
I think pretty much every corporation that can have had this thought, has had it. Really "any popular software" where they can provide similar functionality. And I think this is going to happen more often before it becomes less common.
> While EmDash aims to be compatible with WordPress functionality, no WordPress code was used to create EmDash. That allows us to license the open source project under the more permissive MIT license.
Ha ha, that's really funny timing given the recent launch of Cleanroom As A Service, promising that you can licensewash other peoples' code quickly and easily: https://malus.sh/
I'm not saying they did that, but it's ironic timing.
An edge-first CMS is cool. I've wanted something that works well alongside Astro for ages.
That said, WordPress is a weird paradigm to be replicating in 2026. WP won on extensibility, but the actual legacy of that ecosystem is bloat, security disasters and dogshit performance.
What I think makes more sense is this kind of edge backend paired with a proper modern authoring experience with visual control like Framer/Webflow with Notion-style database primitives underneath.
And given how fast AI is getting at generating bespoke business logic, building another monolithic plugin ecosystem feels like solving the wrong problem.
Plugins were a workaround for the fact that most people couldn't write code. That's increasingly not true.
So this is just a "similar" CMS to WordPress in that it has themes and plugins, and you can publish pages, posts, tags, categories, etc. But there are lots of similar CMS out there, and this one isn't "compatible" with WordPress since you obviously can't just take a WordPress theme or plugin and install it in your EmDash site. So I don't even know why the focus on WordPress here - this is just yet another CMS that offers similar features.
WordPress is the most popular CMS, and, at any moment in time, especially lately, there are a lot of people looking for a "WP alternative". I agree that it's not actually compatible, but it seems they tried to make it similar just enough to be able to use the word without 100% lying and attract people that way.
Nobody is looking for wp alternatives, if they were they would have moved long ago, as there are tens of similar CMS's that were supposed to be much "better" on paper yet never took of like octobercms,gravcms,ghost,netlify,wagtails,etc
With WP you can find a plethora of cheap PHP hostings that offer WP preinstalled.
If you need to tweak a theme - just download a .php file via FTP, tweak it and upload back.
No server management or restart is required.
One big potential benefit that EmDash has - every WP deployment is basically a honeypot.
It looks like I'm in the minority after reading this comments, but I'm quite happy to see this announcement.
A "good" standard, free CMS with theming and plugin support without the issues of Wordpress is _welcome_. (And the issues are many: Licensing, trust, drama, security, and cost).
I'm guessing that a lot of cynicism here is coming from this crowd not being the target market of Wordpress in the first place? What were you recommending to non-technical friends and family who wanted a good, open source, affordable CMS to back their website? Wordpress has all the right _ideas_, but the wrong implementation.
There are great standard CMSes that do everything technically better than Wordpress (not that it's harder to jump higher than a rock, but hey). That's not the hard part. Every developer should build a good CMS once.
The hard part is displacing Wordpress market share; building a community of bloggers, marketeers, agencies, web designers, and so on; creating a huge ecosystem of paid and free plugins, allowing plugin devs to commit to your marketplace and lock customers in.
Wordpress is awful. The only thing it's got going is its moat, but that's not an engineering problem, but a people problem instead.
Those standard CMSs that are technically "better" than WP, I would bet they are at least over a decade old, some have even come out during the same time with wp when there was no market share to speak of and still were left in the dust.
The problem is that people misunderstand why WP was and is better than all alternatives that tried to take it's place, I have no idea either but I know that others have tried same thing as CF and failed.
I have been one of the maintainers of a moderately successful CMS back in the day, but there are definitely well-groomed alternatives that have popped up a lot more recently than that, especially from the headless variety.
I'm convinced the thing that WP did better was being the first simple and accessible blogging platform when blogging was still a thing. IIRC, the alternatives were things like Joomla or Drupal - awful behemoths for enterprise users. WordPress was a breath of fresh air compared to those, and out of the blogging scene, people started to use it for agency projects, while others published an ever-increasing number of plugins and themes. The rest is just momentum of that movement.
I find it hard to believe that people used to WordPress, with its flaws and virtues(yes, wordpress have virtues), will switch to this, no matter how much it's from Cloudflare.
I think the cynicism is related to cloudflares recent previous releases that were considered to be slop that significantly overpromised on its capabilities/completeness. Trust can take a long time to rebuild.
Throw in the the bragging about slop and cleanroom clones to avoid AGPL, the name and April 1st launch date, and maybe the high priority afforded to agent-friendly crypto payment infrastructure if anyone was paying attention. Maybe they prompted the marketing agent with "how can you get HN to loathe a product as innocuous as an open source headless CMS?"
Other than that, it seems it might be a half decent headless CMS, if the bit of WordPress you want is its interface, and not the number of plugins and devs and not being tied to Cloudflare's infrastructure.
> I'm guessing that a lot of cynicism here is coming from
...the fact that CF just dumps tokens to generate some slop to compete with the single biggest web platform and casually adding a vendor lock in. It's just buzz, an inexpensive attempt to grab a valuable market share.
If you set security as a selling point for EmDash, then I am baffled. The WP lock file has 30k lines, the brand new EmDash has 16k lines, but it LESS verbose yaml. JS is the cornerstone of anti-security that WP couldn't dare to compete with. The plugin isolation is also bogus, WP plugins are insecure because they have all access to everything, but they need at least some, mostly DB, how is that even solved? Isolation does shit there.
I am not a fan of WP, but CF doesn't even try to get this right.
Frankly, you're wrong. This is a fundamentally better plugin architecture that WP, and if you can't see it, then it's your understanding of security that's not right.
The post literally does that. it talks about how plugin access to core is handled. So to be explicit: if you don't see that as a very significant security improvement over WP's open world, then it may help to understand why. The post also talks about WP ecosystem downside due to this.
I can't believe as developers we were worried about AI training on licensed code. It turns out it didn't matter at all. You can just point an LLM at some source code and you're off scot-free.
This is naive thinking you can just rewrite WordPress and think it's going to solve any problems that exist with WordPress. The entire community of WordPress has been built over decades including its successes and failures, but people are not going to just stop using WordPress as I have seen people attempt this over and over in the last 20 years with little success.
In my view, Astro is the most reasonable choice for a blog-like website these days. All the simplicity and all the capabilities that you need. Excited to check this out and see what they have added on top of it.
After all these cases like axios it's definitely reasonable. But many people already use Astro. And with static website there are far fewer attack surfaces compared to a full-on PHP running WordPress on a VPS.
I don't like that they see the main selling point that the license, is not GPL, and that plugins don't have to license it that way either. I understand that not all developers are comfortable with the GPL license, but it allows to the code continue to be open source and that most plugins are open source also
A big issue with WordPress is the GPL. There hasn't been much clarity about it and the interpretations I've heard from Automattic in regard to which code is and is not covered by the GPL come from Automattic, not from the GPL. https://redsweater.com/blog/825/getting-pretty-lonely
It's a shame they don't seem to try to address the divide between CMS's and static sites.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
I've been migrating a few Wordpress sites from Wordpress to Astro + Strapi recently, working in 'hybrid mode' so the entire site is static except for post previews in Strapi (only that one route is SSR).
Editing content in Strapi, once customized with CKEditor and such, is Wordpressy enough for the human Editors familiar with WP.
EmDash with some aggressive caching and SWR is effectively this, and we're getting closer to that every day. When the cost of maintaining the data part of the CMS is effectively free, you're basically working with a static site anyway.
I haven’t used Wordpress for a few years. But with WP Super Cache (1) we also always did pretty much that: On saving a post/page the static HTML would be written to a cache directory and be the default content served to visitors.
Depends what you would call that architecture then I guess!
I run my local theatre website by writing the posts in markdown, and then have some github actions which use Hugo to turn it in to a static site and then uploads the content to an S3 bucket. The site itself has dynamic content like within-website ticket buying from eventbrite and a contact form that sends email using an external service. It also calls in things like google analytics.
Does this still count as static? Personally I think so, Even though there are 'dynamic' elements.
IMO static refers more about how the content is served rather than saying that the content can’t be ‘dynamic’ as lots of Wordpress sites have static/non interactive content but still regenerate the html on each page load.
I don't even think the WordPress editor is very nice. It's completely separated from how the actual results look. There are CMSs which lets you edit directly in the web page exactly as it will look when published.
As do most productivity software, like MS Office, Photoshop, Apple's iWork, etc.
Imagine making a document in Word, and it looks completely different when published.
It is written in typescript not php - so not a successor of WordPress.
Typescript is a complete other Story. With compile step and build Pipeline. All not necessary in php
It's great that they are recreating much of the fundamental software stack using LLMs. But if you're going to 'vibeslop,' at least do it in a language other than JavaScript.
I struggle to understand why anyone would want to generate code in TypeScript - unless what you're building truly can't be done in Go, Rust, or Kotlin; anything but JS.
I’m not sure how much of an improvement it really is to rewrite something from PHP to TypeScript while claiming security benefits.
Given how shitty it looks and behaves, I was 100% sure this was an April Fools. But after reading the serious comments here on HN, I'm not sure anymore...
Security by reducing attack surface is underrated as a design philosophy. We took a similar approach for a PDF tool — moved processing client-side entirely so there's no server to compromise in the first place.
I used to host a wordpress on my server for some people who configured it. However, when some bots got there, I was unable to keep them at bay. I upgraded WP's version, but the Wordpress had some vulnerable plugin, and I was unable to find out what path did the attack go. I only could find that the malicious files were uploaded into images/ directory and run from there. That's something I blame PHP for (and of course my lousy LAMP configuration skill, but the directory was not allowed to run the code from, I must impress). I tried also to block IPs attacking my server, but this was like cutting one of the hydra's heads.
So, long story short I ended up removing write permission to all the folders, thus disabling upload, and later they went to another server. They host it fine there, I still maintain redirection from the main domain to their host. However I failed, but really this is sad the WP is so vulnerable just by the plugins installation.
Since then I am looking for WP replacement that would not mix up the code and the images from the upload directory (presumably in rust or golang), but this would need to be opensource anyways.
Will you look at it. Another Wordpress “killer”. Wordpress has that market share because it can be easily installed in a wide variety of servers and because of its plugin ecosystem of dozens of thousands of plugins and huge flexibility/customizability. Wordpress is one of the most flexible pieces of software out there and none of the competition seem to get why Wordpress is so popular.
base platform used - typescript - means for the average Joe out there - deploying is difficult - compared to php.
if they really wanted to be revolutionary - they would've made a single PHP script either on FrankenPHP backed by sqlite - single file deploy - with yeah a permission model Ala denojs for the security aspects.
Its kind of annoying that CF would use an LLM to build something and try to pass it off as something built from "the ground up". Its just copying the library that was already build and passing it off as their own.
Serious question: Who actually builds stuff on Cloudflare workers? I mean large software projects / services, and not just side projects where the ability to scale-to-zero is perhaps more important than the scale-to-infinity direction. I feel like Cloudflare keeps pushing workers with its full force yet I fail to see the appeal.
I'm building a commercial SaaS product on Workers. Although I've barely scratched the surface of what Cloudflare offers¹, so far it's been great. The value proposition is effectively the same as serverless in general: You worry about the product, they worry about deployment. Note that Cloudflare Workers is just one (albeit important) star in their constellation of capabilities.
Me. I used to deploy everything via Docker swarm but recently migrated everything to workers because wrangler is awesome, it makes blue/green very simple, and it's a lot less of a headache for me to maintain in general. It's a great/flexible product. I also use R1/R2 pretty extensively.
Functional April Fools, the best kind. A couple years ago Eleiko, a weightlifting equipment company did one, the 'Heavy Mug', a 19 poundish steel coffee cup with a handle in the style of a knurled bar, and actually did a limited run of them.
> But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
> no WordPress code was used to create EmDash
Hm. Do you think those agents were trained on WP code?
> Most abstractions in software exist because humans need help...It's not clear yet which abstractions are truly foundational and which ones were just crutches for human cognition... We took an API contract, a build tool, and an AI model, and the AI wrote everything in between.
The thing that has always stood out to me about WordPress, is that you can get a site up without any of the usual technical steps I associate with creating a site, but still have access to the innards of the site. Does it often go wrong, sure, but it is a lot more approachable for less technical users.
In contrast, typical web frameworks (even static sites) require a code change, build, deploy, etc to update many aspects of a site.
That used to be a major selling point because hosts enabled PHP for a directory devs would FTP things into, but those days are thankfully long gone. I don't think it's any more difficult to host a JS, TS, or anything else, app than it is to host a PHP app today. In fact, PHP is probably more difficult than something like Netlify.
With PHP you can still drop a single file on shared hosting and be up in minutes, with no build step or CDN proxy in the mix.
npm deps adds plenty of attack surface on its own. Netlify is fine until you need custom binaries or persistent storage, then it gets weird fast. PHP has plenty of warts, but the ops path stays flatter than Node for the boring case most sites need.
All PHP is going to be replaced with single binary Rust apps.
Talented teams will build the atoms for most apps - blogs, CMSes, ticket systems, forums - and it'll be easy for end users to configure.
Rust is easy to code gen and deploy now. No barrier to understanding lifetimes. It's the language everyone should be using Claude Code to emit.
Everyone is now a Rust engineer with 10 years of experience. (I'm not joking, just in case that needs clarification.)
If you haven't tried writing a simple web service in Axum or Actix plus SQLx, you need to give it a try. You'll be amazed at how simple it is, and you'll be even more amazed at how performant and easy it is to work with.
You do not need to know Rust or have any prior Rust experience. You'll pick it up along the way. It's easy and you'll learn it fast.
Rust is a low-defect rate language to serialize to. The syntax begs you to handle errors, nulls, exceptional conditions within the language itself. This is naturally a good fit for most business problems. It doesn't hurt that the language is fast as hell and super portable either.
If the job is now encoding business logic - this is the optimal serialization that I'm aware of. I write Go, Java, Python, TypeScript, PHP, Swift - I can't think of any better language for greenfield projects that don't have existing language/library requirements.
I'm not sure you appreciate why PHP was successful. You might be completely right about all this, but the LAMP-stack "just upload this file to shared hosting" workflow is what made apps like WordPress win out, and the barrier remains significantly higher to do the equivalent with Rust.
I have a love/hate relationship with WordPress. I prefer it over any other CMS for reasons I can't fully explain. Probably nostalgia. I love the editor, the sidebar, the ability to find niche plugins in an endless marketplace, and how easy it is to get a site running.
What I don't love is how insecure it is. You're entirely dependent on plugins (if you're not a developer), and if WordPress updates and a plugin goes inactive, you're sitting on a vulnerability. It adds real stress for something that's just supposed to be a fun personal site.
I stopped building on it two years ago, even though I still like it more than Webflow and most alternatives I've tried. It's a bit sad.
Gmail was also launched on April 1st. The fact that it came with 1GB of storage instead of Hotmail, which limited you to something like 20MB, made people think it was an April Fool's joke.
Tell that to the guy who got upset with WP Engine. EmDash is clearly "inspired" by WordPress including in its UI, so there's definitely something to it.
The phrase "spiritual successor to WordPress" is not likely to be judged a trademark violation, though. It doesn't create confusion in the marketplace as to whether Emdash is WordPress.
The problem with WP Engine was that the name is confusing to users who aren't familiar with it. Presumably the WordPress Engine is the core of Wordpress? Or it's the thing powering Wordpress? It's easy to see ways in which an end user could be confused which was which.
Conversely, this product is called something else, and while their blog post references Wordpress repeatedly it's in a way as to make it very clear that this is not that.
Matt got upset because they forked his open source project and built a hundred million dollar revenue business on top of it without contributing anything back to WordPress.
He'd have more of a leg to stand on if WordPress wasn't itself a fork of an open source project.
Matt should have built something open core or fair source licensed - free for customers, but stops competitors from stealing your lunch. He has no legal ground to argue his case now.
It's a much bigger deal with hyperscalers poaching and stealing, like AWS and GCP ripping off and stealing most of the revenue from Redis and Elasticsearch. That's dishonest and evil in my mind.
Totally orthogonal to this issue of marketing comparisons.
WPE never forked a thing. They were a successful company after he backed out of an investment with them, he resented the success, blackmailed them for 8% of their top-line revenue, then threw a tantrum when they told him to pound sand.
the plugin security problem in WordPress was never really a code quality problem - it was a trust model problem. any developer could publish a plugin and any site owner could install it with one click, with no vetting layer in between. TypeScript and serverless doesn't change that dynamic unless the trust model changes too. curious how EmDash handles third-party plugin permissions at the API boundary.
It runs each sandboxed plugin inside its own dynamic worker, with a separate bridge worker to enforce permissions. The worker only has access to its permitted APIs.
the bridge worker as permission enforcement is a solid pattern - the plugin can't escalate by calling APIs directly, everything goes through the bridge. the edge case I'd be curious about is plugin-to-plugin interaction. if two plugins share state through a permitted API, does the bridge enforce granular enough boundaries there, or does the trust model flatten at that layer?
If creating OSS is this low effort, the right question is: What high effort assets, that are valuable to other builders, should open communities be working on? And I think the answer is open source models with open training and open training data.
I'm all for creating new frameworks that are faster and more secure. But I don't see how this one relates to Wordpress (not in PHP, serverless, not "plug and play", dependent on Astro, "AI Native"…).
It looks like a good open source project, but just call it a new CMS. I think calling it a "spiritual successor to WordPress" is just to gain some marketing points.
Ine thing no other CMS tends to get right (for my needs) is Gutenberg. Tiptap, mantine etc.are just no substitute and for someone like me with next to no frontend knowledge Gutenberg was the only option that provided the flexibility and good defaults to keep a decent looking website that my students could also post on with no training.
A while ago I ran claude code in a custom loop (calling it autoclaude; this was last summer) to create a CMS with Gutenberg’s editor but a lean Python backend (github.com/hessammehr/nuCMS). This was in the Sonnet 3.7 days and even that model got quite far.
Reading the comments below, have we all fallen for a 1st April Fools' joke?
Actually, rebuilding WordPress without the ecosystem is kind of the point. For example, would Divi or the major page builders rebuild their entire products to support this? I doubt it
"Plugin security is the root of this problem. Marketplace businesses provide trust when parties otherwise cannot easily trust each other. In the case of the WordPress marketplace, the plugin security risk is so large and probable that many of your customers can only reasonably trust your plugin via the marketplace. But in order to be part of the marketplace your code must be licensed in a way that forces you to give it away for free everywhere other than that marketplace. You are locked in."
There was much drama with wordpress some time ago and the plugin marketplace.
i have been a admirer of wordpress plugin system and had been shouting for modern alternative with explicit capability model for sometime. I also have been building own composable app platform (not cms) and this looks kinda great actually.
The UI doesn't seem geared to power users. E.g. Why is the featured image taking up so much space above the content editing area when it's sized appropriately for the sidebar? Imagine you need to update the text of several posts... Well, now you gotta scroll down half the page to the content area of each one.
And all that padding gets you quite the narrow content area. Not to mention it looks like a very basic TinyMCE. Seems like more of a POC than an actual "spiritual successor".
The generous take is that this is someone's pet project that marketing got too excited about, and that the leadership haven't applied their minds to. GPL provides a moat for the community, who are contributing their time and energy into a project. It ensures that, even if a commercial company grabs your software, extends it, and commercializes it, that you can fold those improvements back into your original distribution. While the commercial entity benefits from your free labor, you benefit back from theirs.
Re-implementing WordPress (their words, not mine) as MIT licensed, while legally questionable, breaks that virtuous cycle and removes the community's moat. They've taken WordPress's roles and menus and borrowed its Gutenberg code (which is GPL), and launched it as an MIT licensed product, which breaks that virtuous cycle. It means e.g. a hosting company can take the product closed source if they want to, and never have to contribute any of what they build on top of the community's work, back to the community.
Emdash uses WP's RBAC roles. Also uses their menus. Also depends on @wordpress/block-serialization-default-parser which I think might (??) be able to be used by an MIT project even though WordPress is GPL.
They used Claude Code it seems because the first commit has a CLAUDE.md file which became an AGENTS.md.
If I could smash a button and get a 1:1 copy of my existing site, I’d do it in a heartbeat. I don’t see that happening just yet due to the integrated forum software and its own plugins.
With Cloudflare behind it, hopefully plugin vendors will start paying attention.
So it’s a WordPress successor that doesn’t support any WordPress plugins (since they’re written in PHP and this is written in TypeScript) and has baked-in support for blockchain payments. and also it’s “AI Native”, because the internet definitely needs more AI slop blogs.
This IS an April Fools joke, whether or not they intended it to be one.
I mean the creator of the commit takes authorship, just like the auto-complete in old style IDE. Using agents requires a skill, that varies from vibe to advanced.
I have long wanted a static blog with a backend content manager that runs serverless. Love seeing this, but we will see if Cloudflare maintains it in the long run.
I really hope Cloudflare is ready and willing to stand by this thing for the next 20 years, and drive it as a first class product with a huge open source team. Because short of that you can just add this to the mile-long list of "successors to WordPress" we've been through over the decades. Maybe they're in it for the long haul. We'll see. But it takes time, and mountains of integrations and acceptance into the wider web authoring ecosystem for anything like this to gain real adoption.
(To be clear, I'm no fan of WordPress either, and its security hassles are a real issue. But some sloppified MegaCorp vibecoded fever dream will never be a suitable replacement, of that I guarantee.)
The plugin security model in WordPress has been the elephant in the room for years. Any plugin can execute arbitrary PHP — there's no sandboxing, no permission system, nothing. It's wild that we accepted this for so long.
The Cloudflare Workers approach (V8 isolates) is fundamentally better because it enforces boundaries at the runtime level rather than relying on developer goodwill. Curious to see how they handle the migration path for existing WP sites though — that's where projects like this usually die.
I am not fluent in Cloudflare-lingo. What is "Dynamic Worker" and how can I run it outside Cloudflare?
The repo says "depends on Dynamic Workers ... Dynamic Workers are currently only available on paid accounts" but the article says "but you can run it on your own hardware".
I mean it's cool your created a new CMS and all, but beyond the look of the admin interface and publishing flow, I don't see how this is a "Spirtual Successor" to WordPress at all.
Its a CMS, designed from scratch, for a serverless world. It has a stricter, well defined API that plugins are forced to use instead of directly calling/overriding core functionality like in WP. But that benefit comes with a CMS that's built on top of, and seems to prefer, a ton of CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things).
Maybe not scratch scratch: "And under the hood, EmDash is powered by Astro…"
> It's built on top of, and seems to perfer you use CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things.
D1 is SQLite, R2 is S3, and there are other ways to securely run plugins. If it was designed to only be possible to deploy on Cloudflare, they didn't do a very good job.
If Cloudflare really have radically changed their software development philosophy lately, this would actually be an interesting project, being based on Astro and coming with some APIs for programmatic management.
Them being so happy about the „cost of software development“ and not going very deep into ecosystem, community or project management doesn’t convince me that this is going to be a worthwhile project, even if, unlike their previous vibe coding demos, this one actually works.
I'm the main engineer on this. I've also been on the Astro core team for two years, so I do think I understand real open source software and community.
As the post implies, I did use a lot of agent time on this, but this isn't a vibe-coded weekend project. I've been working full time on this since mid-January.
I think one of the reasons people think this is slop is because of the name. How does the name EmDash relate to being a wordpress spiritual successor? It's clear the name was chosen as it relates to the use of em dashes in AI generated text, so why would you want to be associated with that? Why not choose a name like Astro Press given your experience on Astro?
Not sure why you’re being downvoted. The name is so bad. WordPress is a great name for normies. Something like Cloudflare Press would make more sense. EmDash is at best a temporary meme.
Does Cloudflare use EmDash in production? Showing that its design and implementation have been refined through real-world use would help instil confidence.
1- EmDash plugins are written in TypeScript, not PHP
2- EmDash plugins have a specific permissions model, where they need to explicitly request access to certain things.
3- WordPress plugins just invoke things. EmDash plugins have a defined API you use to talk to different capabilitites
4- Those capabilities are totally different, and at a different abstraction, than what WordPress provides.
Beyond the look of the admin interface and publishing flow, I don't see how this is a "Spirtual Successor" to WordPress at all. Its a CMS, designed from scratch, for a serverless world, using CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things).
I agree with you, if you're already a competent engineer, your productivity only is improved by orders of magnitude by using coding agents that are at this point producing very good code as long as you give it the right prompts and you test your code and remove any bugs... if the code tests and all the bugs are removed, what you've got is a working product that is hard to argue that it doesn't work especially if there's been a lot of QA done on it and there's no bugs....
The question isn't whether this took longer than a weekend or whether you personally have open source experience, it's whether Emdash is actually being built as an open ecosystem or as a Cloudflare-bound platform. Bringing up your background reads like using prior credibility to justify the project's quality, instead of demonstrating it.
If it only runs properly on Cloudflare's infrastructure, then invoking "understanding open source and community" feels misleading. Those values usually imply portability and independent ecosystem growth, not tight platform coupling.
Also, "not vibeslop" here isn't about effort, it's about whether there's a clear, defensible reason this exists beyond being an AI-accelerated WordPress-like system tied to one vendor.
The slow enshittification of every product touched by LLMs these last few years (ESPECIALLY by Microsoft, who goes all-in) kind of “disproves” your point.
Reliable agent-coded development only seems to work for small codebases. (And it’s amazing in Ruby for some reasons.)
It's a tough pill for some HNers to swallow, but with a good process, you can vibe-code really good software, and software far more tested, edge-cased, and thoughtful than you would have come up with, especially for software that isn't that one hobby passion project that you love thinking about.
My process is just getting claude code to generate a plan file and then rinsing it through codex until it has no more advice left.
I'd consider it vibe-coding if you never read the code/plan.
For example, you could package this up in a bash alias `vibecode "my prompt"` instead of `claude -p "my prompt"` and it surely is still vibe-coding so long as you remain arms length from the plan/code itself.
I mean to be fair, if you are using agents more than likely you are not thinking about aspects of the code as deeply as you would have before.
If you write things yourself you spend far more time thinking about every little decision that you're making.
Even for tests, I always thought the real valuable part of it was that it forced you to think about all the different cases, and that just having bunch of green checkboxes if anything was luring developers into a false sense of security
There's definitely a trade-off, but it's a lopsided one that favors AI.
Before AI, you were often encumbered with the superficial aspects of a plan or implementation. So much that we often would start implementing first and then kinda feel it out as we go, saving advanced considerations and edge-cases for the future since we're not even sure what the impl will be.
That's useful for getting a visceral read on how a solution might feel in its fetal stage. But it takes a lot of time/energy/commitment to look into the future to think about edge cases, tests, potential requirement churn, alternative options, etc. and planning today around that.
With AI, agents are really good at running preformed ideas to their conclusion and then fortify it with edge-cases, tests, and trade-offs. Now your expertise is better spent deciding among trade-offs and deciding on what the surface area looks like.
Something that also just came to mind is that before AI, you would get married to a solution/abstraction because it would be too expensive to rewrite code/tests. But now, refactoring and updating tests is trivial. You aren't committed to a bad solution anymore. Or, your tests are kinda lame and brittle because they're vibe-coded (as opposed to not existing at all)? Ok, AI will change them for you.
I also think we accidentally put our foot on the scale in these comparisons. The pre-AI developer we'll imagine as a unicorn who always spends time getting into the weeds to suss out the ideal solution of every ticket with infinite time and energy and enthusiasm. The post-AI developer we'll imagine as someone who is incompetent. And we'll pit them against each other to say "See? There's a regression".
I think I agree. Fast iteration in many cases > long thought out ideas going the wrong direction. The issue is purely a mentality one where AI makes it really easy to push features fast without spending as much time thinking through them.
That said, iteration is much more difficult on established codebases, especially with production workflows where you need to be more than extra careful your migration is backwards compatible, doesn't mess up feature x,y,z,d across 5 different projects relying on some field or logical property.
Unless you go through the code with a tooth comb, you're not even aware of what trade-offs the AI has made for you.
We've all just seen the Claude Code source code. 4k class files. Weird try/catches. Weird trade-offs. Basic bugs people have been begging to fix left untouched.
Yes, there's a revolution happening. Yes, it makes you more productive.
But stop huffing the kool-aid and be realistic. If you think you're still deciding about the trade-offs, I can tell you with sincerity that you should go try and refactor some of the code you're producing and see what trade-offs the AI is ACTUALLY making.
Until you actually work with the code again, it's ridiculously easy to miss the trade-offs the AI is making while it's churning out it's code.
I know this because we've got some AI heavy users on our team who often just throwing the AI code straight into the repo with properly checking it. And worse, on a code review, it looks right, but then when something goes wrong, you go "why did they make that decision?". And then you notice there's a very AI looking comment next to the code. And it clicks.
They didn't make that decision, they didn't choose between the trade-offs, the AI did.
I've seen weird timezone decisions, sorting, insane error catching theatre, changing parts of the code it shouldn't have even looked at, let alone changed. In the FE sphere it's got no clue how to use UseEffect or UseMemoization, it litters every div with tons of unnecessary CSS, it can't split up code for shit, in the backend world it's insanely bad at following prior art on things like what's the primary key field, what's the usual sorting priority, how it's supposed to use existing user contexts, etc.
And the amount of times it uses archaic code, from versions of the language 5-10 years ago is really frustrating. At least with Typescript + C#. With C# if you see anything that doesn't use the simpler namespacing or doesn't use primary constructors it's a dead give-away that it was written with AI.
I feel this is the key - three years ago everyone on HN would be able to define "technical debt" and how it was bad and they hated it but had to live with it.
We've now build a machine capable of something that can't even be called "technical debt" anymore - perhaps "technical usury" or something, and we're all supposed to love it.
Most coders know that support and maintenance of code will far outlast and out weigh the effort required to build it.
Produce this "far more tested, edge-cased, and thoughtful" vibe-coded software for us to judge, please.
All I hear are empty promises of better software, and in the same breath the declaration that quality is overrated and time-to-ship is why vibecoding will eventually win. It's either one, or the other.
I’ve said it before here, but my mind was swayed after talking with a product manager about AI coding. He offhandedly commented that “he’s been vibe coding for years, just with people”. He wasn’t thinking much about it at the time, but it resonated with me.
To some agents are tools. To others they are employees.
I had a similar realisation in IT support - I regularly discover the answers I get from junior-to mid-level engineers need to be verified, are based on false assumption or are wildly wrong, so why am I being so critical of LLM responses. Hopefully some day they’ll make it to senior engineer levels of reasoning, but in the meantime they’re just as good as many on the teams I work with and so have their place.
its the same thing. no one can keep up with their plan mode/spec driven whatever process. All agent driven projects become vibe coded "this is not working" projects.
Lot of ppl are only in the beginning stages so they think its different because they came up with some fancy looking formal process to generate vibe.
What are some other candidates in the "most meaningless new term" awards category? "Vibe coding" seems like the best in a generation. Even with a lot of clarifying qualifications, it often still seems fundamentally meaningless / open to interpretation / triggers commenters based on their priors.
I started calling it LLM assisted coding. If you know what you’re doing but use LLMs to do tedious stuff and educate yourself on the unfamiliar bits you can move quite fast. The term vibe coding does not do that process justice imho.
> The term vibe coding does not do that process justice imho.
Well that's because actual vibe coding is a completely separate thing from "LLM assisted coding, know what you’re doing but use LLMs to do tedious stuff".
I'm not entirely sure what you mean by "started calling it", but vibe coding doesn't need a new name, it needs people to be clear about what they mean.
I think the jury is still out on this one, meaning people have different meanings when using the term "vibe coding".
OP says "vibe-coded months long project", imho that is not vibe coding? I'd say it's vibe coding if op does not know the programming language and just let the LLM write everything. This does not sound like it.
Exactly. It might be fine. It might even be great!
But no matter how much code, including tests that AI can generate there was only one human thinking about those prompts, for a few months.
Any defects in that single human's thought process for overall architecture, security architecture, test architecture and coverage were not reviewed by any other human who might think differently and catch things that were missed. Ideally they were all at least reviewed by AI, but how differently operate from itself? It isn't particularly good at detecting its own errors without a human telling it to, which means the human needs to detect it in the first place.
Perhaps my most important point here is simply everyone here on HN is aware of all of these things, and as excited as some of us are about AI coded endeavors, the top response here will likely be the top response for many years - how do I know it isn't garbage? AI might be able to generate code fast, but informed users will definitely develop trust in it on a more human time scale.
I think the core idea of addressing a core architecture security defect in Wordpress has a legs. I'd make the case that the security architecture demonstrated here is table stakes for new software projects in 2026 when it clearly wasn't really conceivable in 2003. Though I'd also argue that many of the top Wordpress plugins should be shipped as "batteries included" in any successor, spiritual or otherwise - it would remain important to be extensible beyond those, securely.
A spiritual successor to Wordpress designed to run modern cloud infrastructure is a neat thing no doubt.
But after handling a bunch of horrible Wordpress and PHP stuff in my life lately, I'm tacking a bit of begging onto my hopefully useful response. Someone, anyone, AI coded or not, please work on a COMPLETE successor to Wordpress. And PHP really - though I do think taking care of Wordpress would entirely deal with the PHP problem.
What do I mean? All the modern table stakes stuff:
* API first
* fast bits in Rust (or Zig whatever IDK)
* WASM
* modern security architecture
* batteries included - it is extremely dumb to have to add a plugin for calendars/dates/events and have about 100+ options for those.
* designed to be deployed into modern clouds.. but also self-hostable on a single server, or colocated by small (cheap!) providers - ie: addressing ALL of the user base of Wordpress
* one-click migration from Wordpress. Wordpress does this "with itself" to allow admins to move from one provider to another. Without this feature, might as well not bother
There is a business opportunity here I believe, though I'm not proposing a business model per se. A lot of people, myself included pay for Wordpress hosting while also hating it and being ready to leap at an alternative - even if it cost more.
This crap thinking has to stop, not everything is "hey agent do this" then sit, wait and publish as is. Also this is a Cloudflare official software, do you REALLY think this is 100% vibe coded without human intervention? Come on...
While I agree with your first sentence, I haven't been impressed with cloudflare's AI track record. I think my expectations for "cloudflare software on the HN front page that was significantly AI coded" are lower than "random guy's software on the HN front page that was significantly AI coded".
Considering Cloudflare shat out slop in the form of a "complete rewrite of NextJS in one weekend" and proudly put out a blog post (https://blog.cloudflare.com/vinext/) despite how absolutely dogshit it is:
> But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
They have honed their AI OSS troll marketing chop and every step goes far and far. I'll take it more seriously once they start open sourcing vibe coded projects they actually use in their production.
I think Cloudflare has picked up that code velocity is only good if you can recruit users to a new open project, and have solid maintainers to keep the project going long term. Just from passive observance it feel like Cloudflare’s engineering team is chockful of seasoned maintainers. They then have a great social following already. So, code velocity, plus audience, plus maintainers, means you maybe can capture a lot of open projects under your umbrella while people are still trying to figure out how to fiddle with legacy software and AI. Meanwhile, “new is always better” puts pressure on legacy user bases. Finally, you allow these things to hook into your magnanimous global app development platform, and boom you have got it made in the shade.
I'm getting so exhausted of the "slop" accusation on new project launches. There are legit criticisms of EmDash in the parent comment that are overshadowed by the implication it was AI coded and, thus, unusable quality.
The problem is there's no beating the slop allegation. There's no "proof of work" that can be demonstrated in this comment section that satisfies, which you can see if you just keep following the entire chain. I'd rather read slop comments than this.
The main engineer of this project is in the comments and all he's being engaged with on is the definition of vibes.
They called the project EmDash and launched it on April 1st with a blog which brags about how little effort it took to write because of agents before even saying what it is.
If the product launch involves dressing the engineering team up in duck suits and releasing to a soundtrack of quacking, it's really not surprising people are asking the guy they hid behind the Daffy mask on why he's dressed as a duck rather than what he learned about headless CMS architecture from being on the Astro core team...
I know that it's discourteous to write-off a potentially valuable project because the release post showed a lack of self-awareness, but I think it's indicative of the larger struggle taking place: that trust is decaying.
It's decaying for a lot of the reasons displayed in the post, like you described, but the post also:
- is overlong (probably LLM assisted)
- is self-congratulatory
- boosts AI
- rewrites an existing project (vs contributing to the original)
- conjures long-term maintenance doubt/suspicions
- is functionally an advertisement (for CloudFlare)
So yeah, maybe EmDash is revolutionary with respect to Wordpress, but it hasn't signaled trust, and that's a difficult hurdle to get past.
There's plenty of other comments saying this. It isn't that I don't understand, and need a clever metaphor.
But to run with your metaphor, can we, maybe, just ignore the quacking since we all know that's just how you get attention these days and instead focus on that other stuff? Because it seems like asking about the duck mask will never produce a satisfactory answer and instead turn into a debate on the merits of ducks.
Dare I suggest that this debate has become boring and beside the point. Unless someone on HN has been living under a rock they've already made up their mind about ducks.
Obtuse and repetitive debates is what HN comments are for. :)
But in this case it feels less like somebody has launched a revolutionary new product and HN is debating the MIT licence and landing page weight, and more like somebody has announced they've a plug-in replacement for a popular repository with a troll post and HN chooses not to spend enough time on Github to discover the all-star team and excellent architectural decisions the blog didn't bother mentioning.
Plus Cloudflare deliberately signalling that at best they're not very invested in its success and it might well just be low-effort slop probably is more pertinent to whether a purported WordPress replacement actually gains any traction than its technical merit, and headless CMS with vendor lockin vs managing WordPress security isn't likely to be a more productive debate than one on "slop". The target audience for this product is much more 'HN crowd' than 'read about agentic solutions to workforce automation on Gartner crowd' too, so the quacking alienating HN is actually relevant.
Maybe what the parent commenter was referring to is that recently CloudFlare have published multiple vibe-code demo blog posts whilst trying to pass it off as production grade, for example https://news.ycombinator.com/item?id=46781516 where they implemented an open standard communication protocol on CloudFlare Workers.
The blog post was chock full of factual errors, claimed to be based off project X but wasn't at all and even had the cheek to include that it was arguably the most secure way to deploy such a server, with their implementation apparently already being used by their team to serve real traffic. Meanwhile the repo was full of TODOs for all the security aspects of the protocol.
Of course after the backlash a lot of this was covered up so look at the archives if you are curious.
They have really done a disservice to themselves because their blog posts used to be excellent, but now I have to question whether it's another blogpost full of fakery like that one (and there was another since iirc).
Given this blog post talks about reimplementing a popular project, it starts to give off the signs of being another one of these. Unfortunate if that's not the case
IMO, what matters is whether it's coded with AI or it's coded by AI.
Is AI merely being used as a tool to aid the engineer? Because that's what I do. I use it as essentially a super-autocomplete. It typically only writes a couple lines at a time for me. On rare occasions, I can write a function signature and let it fill out the body. That's coding with AI.
Anything more than that though? You're stepping into coding by AI, which utterly fails at anything beyond an MVP. Once you go over 2,000 lines of code or so, it falls apart. It can't reason about anything with even a small amount of complexity, and every "bug fix" either fails to fix the bug or it introduces two more.
whether people want to admit it or not, agent encoding is kind of the norm right now and I think the fear is the stories coming out of places like Block, Inc where they announced they fired 4,000 engineers a couple days ago because of what's the obvious truth today versus 6 months ago.... one expert software engineer can do the work of 20-40 people, so why do we need so many people? it's a hard pill to swallow, it's easier to claim that agentic coding doesn't work or that the code is sloppy and it doesn't work when in reality most companies are currently using it everyday, especially the large ones.
The problem is that it doesn't solve the network-effect problem.
People aren't on WordPress because of WordPress.
They're on WordPress because of WooCommerce, a million themes, BuddyPress, integrations for every stupid internal business API on the planet (many of which are terrible and were written by an idiot with a crayon).
The APIs will have no testing because they are bad. In many cases the WordPress implementation of the API written in the codeblock, ran on page-load to the pain of the person responsible for SEO, is the API contract.
And yes those plugins are also terrible, but they solve business problems, even if they are tech problems.
You can't just launch a better wp-core and expect it to replace any of that.
EmDash needs to actually run the existing insecure WP plugins to takeover.
You seem to have missed the point. This is intended to be more secure in a new world where exploits will be cheap to discover. The factors you mention won't keep people onboard if systems are compromised every day in too many ways for fragmented security teams to keep on top of.
Having got back in to some WP in the last year, the big thing that struck me compared to other framework/environments is... no... build step, or even plugin/module install step. Files are just there in the document root, accessible by default - the logic files are invokable and the asset files are reachable. Most other php frameworks will install a plugin/module outside the document root then have some sort of publish/install step that will copy assets to be publicly accessible as needed. No plugin logic files would be invokable directly from a URL. That one change would make a big difference, imo, but seeing so much of the last 15-20 years of WP involves helper functions to assumed paths, and default assumptions about assets and logic living in the same paths... I'm not sure the ecosystem could adapt or support an alternative approach at this stage. Might be wrong. It's taken me a while to put my finger on why the current situation encourages less-secure-by-default systems, and this is probably the biggest thing I've landed on. There are other issues, but these issues all help contribute to WP popularity in the first place...
Your first statement is wildly and verifiably untrue (see: https://survey.stackoverflow.co/2025/technology#most-popular...) and your second statement doesn't make sense. I've got like 8 sites on Pages/Workers with R1 + vectorize databases scattered around and I'm not paying a dime for any of that. What cost are you talking about?
You want anything beyond ghost? Find a way to port the vast market of 100,000+ cheap and free themes and components that are available to enable tech-illiterate, low-budget users to basically build an entire business platform on a $5/mo shared hosting plan.
A vibe coded CMS that's 3 months in the making is not capable of taking that place in the market, no matter how much VC funding you put behind it.
I think wordpress, woo commerce and elementor are in a Mexican standoff. Wordpress cant fork or change in a major way because the other two are so popular no one would use the new variant. woo commercere and elementor can't just walk away and make their own wordpress-less platform because they rely on each other and the other constellation of plugins that run on wordpress.
WooCommerce is owned by the same company as Wordpress. Elementor is just one page builder of many in the vast ecosystem you mention, but much of that ecosystem can be ported. As replacing the core CMS goes, Emdash might be able to conquer, but time will tell as to whether it's able to rule.
This reminds me of Linus Torvalds about Git, criticizing that SVN did present itself as "CVS done right" for... "It's impossible to get CVS right". Which I found incredibly funny and witty.
Is the second coming of Wordpress what we really need?
I think this is too soon to call. No one questions whether AI can build things. We question whether they can build stable things that work as expected and stay online in the long run.
I too have seen a lot of comments asking where the products are. If you're now moving the goal posts to "stay online in the long run" you're gonna have to wait until there's been a long run to stay online in. Agents aren't that old yet.
The stability question is real but I think it's framed wrong. The issue isn't whether an agent can write correct code in a single session -- they can, and pretty reliably now. It's whether there's a human with enough understanding of the codebase to debug it when something breaks at 2am.
I run parallel coding agents on my own projects daily. The code they produce is fine. What worries me is the "just ship it" energy where nobody on the team deeply understands what got built. That's not an AI problem, it's been a problem with outsourced codebases forever. AI just makes it faster to accumulate code nobody fully groks.
Cloudflare probably has the engineering depth to maintain this regardless of how it was built. A lot of other teams don't.
Half the websites on wordpress moved to shopify, squarespace, etc. a very long time ago. The remaining half were blogs, personal pages, wikis, etc. that moved to community/social platforms created in the past decade(s). In a few cases out of all this someone finally learned how to write/host a webpage themselves (imagine that)! It's even easier with AI now.
I'm totally serious when I ask "why". Who actually uses a CMS or anything like that anymore? It's madness!
After all the AI slop from Cloudflare in recent months and the embarrassment that came with it, they dare to launch this vibe coded project with THAT name on April 1st? I'm really not sure what to think anymore. Reality became too absurd.
Held up getting into the details of this ambitious project because of the name! Ridiculous choice considering the associations with AI, slop, and even the general crowded namespace surrounding that. C'mon.
(looks for cameras) Wait a minute, am I being Punk'D? Oh my god! Ashton, you really got me! Ha Ha! Ashton!
From the people who brought you "we used AI to undercut a project we use rather than pay them fairly for the work we relied on" comes an exciting new lawsuit by Mullenweg for using Wordpress in their product description.
The Deploy to Cloudflare button in the article is not working for me.
It takes me to the expected Cloudflare dashboard page, with title “Clone a repository” and with the GitHub repository URL field filled with https://github.com/emdash-cms/templates/tree/main/blog-cloud... but when I click Continue, the Continue button changes to “…” and animates indicating it’s thinking, but then nothing happens. No error messages shown, nothing. The Continue button switches back to having the Continue text and being clickable.
I tried deleting a couple of old applications I had in the Workers & Pages page of the Cloudflare dashboard thinking that maybe I had exhausted the number of such applications I can have on a free Cloudflare account. The number of applications I have is now down to 7, after deleting a couple of old ones. Still, attempting to deploy EmDash to my Cloudflare account fails in the same way as before without any error messages shown.
I was using Safari on iOS 18.7.1. I will try on a desktop browser, in case the problem is only happening in Safari on iOS.
Yeah, I had this happen the other day with their Moltworker.
Another one of their products which was “just an experiment”
Cloudflare annoys me as a company.
So this product has nothing to do with wordpress, it's just another CMS that mentioned WP only bcz they created a migration plugin that won't work on 90% of existing wp sites and won't work on 100% of woocommerce sites.
This is no successor, it's not even in the same universe. - vendor lock-in, losing gpl, losing access to plugins source code, loosing ownership.
So it's spiritual successor, not successor.
It doesn't feel connected in spirit at all though. It is in the same category of app though. So there is that. Categorical descendant I'd say.
It's licensed under MIT. It's more permissive than wordpress.
That is not a pure upgrade, GPL may well be the "better" / safer / trusted /... option for some
yeah it's strange, if you are building a CMS in AI times, I think you would want an llm integration first. Not a UX clone of WordPress. The UX of WP is sort of a historical clutch not a plus.
I'd go the other way. Have less stuff. Just a text box, markdown, insane support for mermaid and everything. Dump the "blocks" of wordpress etc. Too confusing and fiddly. Maybe have AI assist to help with styling the rendered page a bit.
> Our name for this new CMS is EmDash. We think of it as the spiritual successor to WordPress. It’s written entirely in TypeScript. It is serverless, but you can run it on your own hardware or any platform you choose. Plugins are securely sandboxed and can run in their own isolate, via Dynamic Workers, solving the fundamental security problem with the WordPress plugin architecture. And under the hood, EmDash is powered by Astro, the fastest web framework for content-driven websites.
To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites.
But of course, then they wouldn't be able to sell their own "workers" product, so suddenly I think I might understand why they built it the way they built it, at the very least to dogfood their own stuff.
I'm not sure it actually solves the "fundamental security problem" in actuality though, but I guess that remains to be seen.
I love building static (or statically generated) websites, but all too often, customers want dynamic content. And what's worse, they don't tell you up-front, because they don't really understand the difference.
"I need a website for my bakery". "What's supposed to be on it?" "Our address, opening times, a few pictures". I build them a static website.
"Now I need a contact form". Ok, that doesn't really fit into a static website, but I can hack something together. "Now I need to show inventory, and allow customers to pre-order". A static website won't cut it anymore.
When you develop for clients, especially those that you don't know very well, it's a bad idea to back yourself into a corner that's not very extensible. So from that perspective, I really get why they give plugins such a central spot.
This is the main reason why WordPress is so popular still to this day. You can cache the crap out of the frontend to the point that it’s basically a static site at that point but then it’s still all running on top of a dynamic platform if you need that flexibility in the future.
I got my start in webdev slinging WordPress sites like a lot of self taught devs and I definitely see the pain points now that I’ve moved on to more “engineering” focused development paradigms but the value proposition of WP has always been clear and present.
Given how WP leadership is all over the place at the moment, I can see how Cloudflare sees this as an opportunity to come in and peel away some market share when they can convince these current WP devs to adopt a little AI help and write applications for their platform instead.
Let’s see if it pays off!
A contact form is a really bad argument for not making the rest of the website static first.
With Astro you can build a static site and if you do want dynamic content later on you can, so you aren't really backed into a corner nowadays.
This is the most underrated point about CMS choice. The cost of migrating from static to dynamic is way higher than starting with a dynamic platform and caching aggressively. WordPress won precisely because you could start with a $5 blog and end up with a full e-commerce site without a rewrite. The question is whether EmDash can match that upgrade path while actually keeping the security promises
That's not why Wordpress won. Every CMS was doing that, and far far better than Wordpress was or is doing even now, two decades later.
WordPress had nothing on Joomla. Drupal was even better, but the barrier to entry was higher.
The only reason WordPress won was that a template/theming ecosystem developed around it faster than anywhere else.
Is this not often trivially solved with islands?
Yeah and this is probably why they said in the article:
“ And under the hood, EmDash is powered by Astro, the fastest web framework for content-driven websites.”
This is why we built https://sumar.io/
> To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites.
To me this wording is strange, since traditional web frameworks do render pages server-side. The specific functions of their templating engines are often even called "render" (https://jinja.palletsprojects.com/en/stable/api/#jinja2.Temp...) or "render_template" or similar (https://docs.djangoproject.com/en/6.0/topics/templates/#djan...). I guess "server-side rendered" is being coopted by the JS ecosystem for some time now, as if they had come up with the very idea of rendering pages on the server side.
It would do the world some good, if people could just look at a technical term, understand its meaning by its components, and then not go: "Ah yes, I will use the same term, but no, no, no, I mean something different by that!"
For this example:
This has been done for decades and the result are usually, for the browser, static web pages. Static as in the opposite of dynamic. Dynamic meaning that the pages react to user interaction, meaning scripting, meaning JS.I think this is true, however, when it comes to non-coding clients I've worked with they really do like the ability to make minor edits to a site with a UI rather than having to continually ping a developer.
The problem with WordPress (and it looks like this solution largely just replicated the problem) is that it's way too cumbersome and bloated.
It really is unlike any modern UI for really any SaaS or software in general.
It's filled with meaningless admin notices, the sidebar is 5 miles long and about 98% of what the user sees is meaningless to them.
Creating a very lightweight, minimal UI for the client to edit exactly what they need or like you said, just static files really is the best solution in most cases. The "page builders" always just turn into a nightmare the clients end up handing over for a dev to "fix" anyways.
Not sure why so many people feel the need to continue on the decades of bloat and cruft WordPress has accumulated, even if it's "modernized."
There are two types of WordPress sites from my perspective as someone who got their start in webdev in that ecosystem.
The first and arguably largest is exactly what you describe. Little sites for small businesses who just want an online presence and maybe to facilitate some light duty business development with a small webshop or forum. These sites are done by fly by night marketers who are also hawking SEO optimization and ads on Facebook and they’ll host your site for the low low price of $100/mo while dodging your phone calls when the godaddy $5/mo plan they are actually hosting your site on shits the bed.
The second, and more influential group of WordPress users, are very large organizations who publish a lot of content and need something that is flexible, reasonably scalable and cheap to hire developers for. Universities love WP because they can setup multisite and give every student in every class a website with some basic plugins and then it’s handsoff. Go look at the logo list for WordPress VIP to see what media organizations are powered by WP. Legit newsrooms run on mostly stock WP backends but with their own designers and some custom publishing workflows.
These two market segments are so far apart though that it creates a lot of division and friction from lots of different angles. Do you cater to the small businesses and just accept that they’ll outgrow the platform someday? Or do you build stuff that makes the big publishers happy because the pay for most of the engineering talent working on the open source project more generally? And all that while maintaining backwards compatibility and somewhat trying to keep up with modern-ish practices (they did adopt React after all).
WordPress is weird and in no way a monoculture is what I guess I’m trying to say.
I have no idea if it’s still true but it used to be the case that you had 3 choices with a Wordpress install and even a couple plugins:
1) Have a part time job updating it and plugins, making sure you weren’t introducing vulns at every step
2) Leave it as is and hope that no vulns are discovered for your particular version or plugin versions
3) Have things auto-update and pray that your plugins don't get sold or compromised and backdoor your site
4) Don't use a stack of plugins, if you must use any keep them as dumb as possible and stick to those with a longstanding reputation.
A basic instance, set to auto-update, installed on a shared webhost where OS/web server updates are someone else's problem is pretty foolproof. A VPS running a long-term distro set to auto update is almost as good.
---
That said I personally dropped Wordpress for static site generation years ago because I realized I didn't actually need any of the dynamic features and wasn't using the WYSIWYG editor. Now I write Markdown in to a file in a git repo and then trigger a regeneration whenever I update it.
I hated Wordpress so much that when the clients wanted an admin dashboard I used a neat PHP CMS called Kirby. It was awesome back then! So simple
It was awesome back then and it's even more awesome now: https://getkirby.com And there's a V6 in the making that should come out soon.
I wrote my own CMS, as the core WordPress functionality wasn't too much to replicate.
But eventually the WordPress ecosystem was too strong, and the real value proposition was plugins and familiarity. That continues to be true to this day, which is why no CMS has de-throned WordPress in spite of significantly better UX, architecture and developer experience. None of it matters when the client has a suite of plugins they have been using for 10+ years, that are now core to their business.
Are you sure the admin notices and sidebar are not plugin issues?
I use Wordpress for my blog because I stopped caring about maintaining one, and I'm mildly confident wp will be around for 10 more years.
There are basically no notices and the admin sidebar is ~10 obvious entries (home, posts, pages, comments, appearance, settings etc).
If it uses Astro, then it's a literal static website generator. But with modern React components if you need anything on top of this. The same with plugins, I assume people don't have to use those but the important thing is that you can if you want to.
Distribution of the content as static html or in any other format is a very tiny aspect of managing content and mostly a solved problem for any CMS nowadays. Focusing on that minimal aspect seems grotesque as there are much bigger challenges in making potentially large amounts of content actually manageable by a potentially very heterogeneous group of content creators with varying skills, responsibilities and relationships.
Sure, but if I want to host my static files on a website where they are easily cached... cloudflare also offers this product?
Astro supports generating static html, so I suspect it'll work similarly where you can have some routes static and others dynamically created.
Astro is a static site generator. This CMS outputs static HTML as an end result, am I missing a concern?
But "back to CMS roots" is absolutely not what the WordPress ecosystem is about. It's about the absolute galaxy of plugins that provide you with an entire digital experience "in a box". You can just install whatever plugins for ecommerce, CRM, forms management, payments, event calendars. They will all plugin to both the template system and the MySQL database. There are a lot of well-known and reputable plugins with huge installed bases (woocommerce, gravity forms, yoast seo) but there's a ton of shady ones that can infect your install. Cloudflare is directly addressing the shortcomings of the existing plugin architecture indicating they intend for EmDash to fill a similar niche as an All-in-One digital experience and not just a simple CMS.
Reading this paragraph I was genuinely convinced it was an April 1st thing.
The question is then they'd be building some brand new thing not compatible with wordpress. Supposedly the proposition is to steal people away from wordpress. Not just get people building something from scratch looking for a new framework. I'm guessing the recent lawsuits also provide some momentum.
It's not compatible with WordPress, though. It slurps a WordPress export, which is quite literally static data. They expect you to code up anything dynamic using their agent skill.
I am confused - what are the good “websites” roots? Server-side rendered or not?
Websites used to be static html files.
You either write them by hand, or use a tool that generates it locally, upload everything and you're done. Perfect security. Great performances.
It's in this sense that static generators go back to the source, the simply produce dumb HTML files that you upload/publish to a web server that doesn't need to run any code. Just serve files.
Imho CMS is just a tool that generates static html files on the server. The distinction is a bit artificial. CMSes have static html cashing and CDNs will allow you to "one-click" firewall the dynamic administration and cache the static html for you.
Static website generators are cool way for programmers to do that work on their machine but in the end the distinction of what gets served is very small (if you set up the basics).
CMSs allow non-technical people to update the site - that's why WordPress, Drupal, and all of the shambling corpses of "digital experience platforms" still command the dollars and eyeballs that they do.
Go ahead and give your content people access to a static site builder and see how quickly the process falls apart. Static site generators are perfect for engineers but terrible for the marketing people that are the actual "customers" of your public-facing website.
I did this, and you are 100% correct.
I used Hugo, told the marketing people to send me a markdown file and I'd load it up to Hugo. That was clearly too painful for them. So I told them to send me a Word doc and I'd convert it to markdown and load it up. That was too painful. I told them to send me an email with the words and images and I'd work out the rest. That was too painful.
They got some marketing agency to rewrite the entire marketing site in Wordpress, and then we had to implement some godawful kludges to get our backend to redirect to their shitty WP host for the appropriate pages. It was awful.
But the marketing folks were finally happy. They could write a blog post (that no-one read) themselves in the actual CMS and see it go live when they pushed the button.
We spent thousands, in a cash-strapped startup, dealing with this bullshit.
Reminds me of Vercel and NextJS, where a popular framework design is constrained by, or optimally runs, on their infra, but then comes with pains or unusualness if self-hosted (eg. middleware). Vendor lock-in plays are a big red flag
It looks like they rolled it so you can plug in local components of your choice, though? The security model does assume you have MAC containerized environments available at your fingertips though, so having something like DHH's once is probably a soft minimal dependency if you want to do-it-yourself.
This is very interesting. I've worked with WordPress on and off for 10 years, and I'm convinced that this project has got 2 things absolutely spot on. TypeScript and Worker plugins.
I've given the security, or lack of, WP a lot of thought recently. In WP malicious plugin has access to the database, enfironment variables, rendering text on screen (think XSS). Luckily, a thoughtfully designed plugin system can mitigate all of those issues.
I've been working on a headless CMS in my spare time that is eirily similar to EmDash in a few ways. It's in very early development, but I will share regardless. It's called HotsauceCMS - https://github.com/hotsauce-team/hotsauce
- I went with optional NodeJS or Deno Worker plugins, this means that first-party plugins can benefit from the speed of in-process, and other plugins can be run in Workers. For fine grained permission control, you can use Deno Workers.
- I went with absolute minimal dependencies, I am so fed up with Dependabot alerts and npm supply chain hacks. My CMS has only 4 dependencies, 0 transistive dependencies.
- It's Drizzle schema first, and headless. So you have full controll of the database structure, use cms hints in your schema for features like file upload.
- It's database-agnostic, so it works with any Drizzle-supported database (Postgres, MySQL, SQLite)
- Being headless, you can use any frontend, my preference is JSX w/o react, but anything goes.
Feedback is absolutely welcomed on HotsauceCMS, did I miss a trick, am I on the right track?
Anyway, congratulations on EmDash. I'll be following closely, excited to see how the next few months unfold.
I personally i am in the other camp and think they got the language change absolutley wrong. I already have php installed on my server why do i need to install TypeScript? The easiest website to run is in php. All other languages add a barrier.
I agree with your sentiment. Meet the customer where they are at, right?
Years ago, I would have said small bussinesses are on cPanel, FTP-ing files to the server. Asking them to run NodeJS is crazy. But here we are, the hosting landscape is vastly different, is it still so crazy to ask a small business owner to put there code on GH, connect GH to a hosting platform and push?
---
Anyway, I doubt you will see people dropping off WP and migrating sites to EmDash. What's more likely will be that it is considered as an alternatave for new projects.
> I'm convinced that this project has got 2 things absolutely spot on. TypeScript and Worker plugins.
Can you explain why TS is spot on?
The main thing is unified types.
- I've been done GraphQL server with a build step to share types between languages.
- I've used untyped JS client side code.
Both are prone to bugs, and not much fun.
TS for front and back end: sharing types means you'll have editor type hints, catch type errors at lint (or build), and you might even share validation logic between client and browser.
I used to work with Wordpress a lot, but last time was a couple years ago.
The appeal for the company i was working with was ease of installation on legacy servers (FTP). You would just upload the files, and it worked. No CLI tools, no dependency management, no build tools.
But yeah, security was a big issue. Constant hacks.
The constant hacks are side effect of Wordpress popularity. Every discovered security flaw is exploited by bots almost immediately. Unless you keep up with the updates you are very vulnerable. It is not because wordpress is built on "legacy" stack. Other CMSes on that stack (and many are very popular) don't have this problem.
The popularity helps, but it’s also because WordPress’s security model is distilled insanity. PHP makes this insanity far easier than most languages, and WordPress embraces that, whereas the likes of Drupal rebuff it.
I think the security issue is that people trust random plugins without reviewing them.
I’ve been running WP with small and large companies and no big security issues. You either build your own plugins or go with the trusted few you need to augment your operation.
Same. I've been working with and managing thousands of WP sites for over a decade and the only issues I've had have been with sites acquired from 3rd parties with random themes and plugins (and old WP versions) that break if you update something. Those have gotten hacked and have caused many headaches.
Basically no issues with sites built in-house. As you say, only reputable 3rd party plugins (like for SEO, caching, multilang) most others made in-house.
https://news.ycombinator.com/item?id=47503348
> I am now scared to talk to anyone. Eventually the conversation turns to AI and they want to talk or show their vibecoded app.
> I am just tired boss. I am not going to look at your app.
Hey, I feel bad for you. I would say try and avoind HN if you don't want to see AI.
But, in this case, I want to respectfully disagree with you. I read the frontpage of HN almost daily, I never really jump into conversations, for this post about EmDash I am absolutely qualified to contribute.
There are precisely 2 open source projects in existence (proove me wrong) where the "Worker Plugin" architecture has been taken. Mine and EmDash. Looking at some of the code examples from EmDash was like looking at my own docs.
If you don't want to look at my app, then fine. But please don't gatekeep, I'm qualified to talk here.
I run a handful of WordPress sites. The plugin problem is real. I've spent more time managing plugin updates, conflicts, and security patches than actually building content for the sites.
But the reason I'm still on WordPress isn't loyalty. It's that my clients can maintain their own sites without me. A small business owner updates their own pages, adds blog posts, changes a phone number. No developer needed. That's not a feature of WordPress. That IS the product.
EmDash solves a developer problem (sandboxed plugins, TypeScript, Workers) by building a developer product. Nothing wrong with that. But calling it a WordPress successor misses why WordPress won in the first place. It wasn't the code quality. It was the guy who runs a bakery being able to edit his own website on a Sunday morning.
Can't you do that editing with EmDash..?
In my opinion, Cloudflare are coming at this from the wrong angle. WordPress is so popular because back in the day it was the easiest way to get a website built. So it got a network effect of engineers behind it which is why it persists at 40% of websites today. Same thing happened with React - majority of Typescript sites are written in React and NextJS because of the network effect around it.
Yeah the security aspect is important, but how many of those Wordpress engineers are going to jump ship to this because of security when they've been fine with the risk so far? My money is not a lot. If someone is a WordPress dev in 2026, they're probably not the type of dev that likes to upskill and learn new tech. Similarly, if you're looking to target the average joe looking to build a fresh website, would that consumer really choose this over Wix or Squarespace? It doesn't look easier to use so I wouldn't count on it. So where is the network effect going to come from to make this the new WordPress?
I could see Vinext being successful if they keep at it— I think there are a sizeable amount of people who would like to move away from Vercel (and who will probably migrate to Tanstack when the ecosystem is more stable). But I'm not sure people on WordPress really want to leave. If they really want to make this successful I think they need a better angle which in my opinion would be making it easier, quicker, cheaper and more flexible than Squarespace/Wix/Shopify etc
The "WordPress devs don't like to upskill" framing is off. Most of them maintain sites for clients who need WordPress specifically. They stay because their clients stay, not because they can't learn TypeScript.
The real talent drain isn't about technology at all. It's the governance mess. The WP Engine lawsuit, Matt's behavior on community Slack, the constant drama. That's what's pushing people out.
But even with all of that, nobody's leaving for EmDash. They're leaving for freelance Webflow work or getting out of CMS entirely. Cloudflare would need to solve the "why should I rebuild my entire business on your platform" question before the talent pool argument matters.
Wordpress has an amazing talent pool of experienced people. EmDash is starting from zero - but you have to start somewhere!
I’m very happy with WP, but I’ll be cheering on EmDash if it gets momentum.
WordPress lost a lot of "experienced people" in the last two years, after Matt Mullenweg decided to wage war on WP Engine.
From the readme on GitHub:
> A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations.
Someone should introduce the authors to the lovely em dash character. It's perfect for such sentences!
I can't help but sense a level of arrogance when they launch their product by writing an obituary for a competitor. Is this what people feel when they make fun of the "(product here) killer"?
It is true though.
We have a cursor subscription and work and i now see many non-technical people building their own internal tooling. People that had essentially never written a line of code before this new revolution.
The cost of building software has really drastically decreased.
> x402 is an open, neutral standard for Internet-native payments. It lets anyone on the Internet easily charge, and any client pay on-demand, on a pay-per-use basis. A client, such as an agent, sends a HTTP request and receives a HTTP 402 Payment Required status code. In response, the client pays for access on-demand, and the server can let the client through to the requested content.
Fascinating. Cloudflare is envisioning a future where agents are given debit cards by their owners, so they can autonomously send microtransactions to website owners to scrape content or possibly purchase goods on the owner's behalf. I don't know how I feel about that but there's no doubt it's a fascinating concept.
Brb, setting up a honeypot that always responds with HTTP 402 Payment Required demanding 10cents per visit... That's the next "selling 1 million pixels on my website for $1 each", I guess
It's naive, nobody will pay, especially not AI companies.
If you can find a way to trick agents into always accepting your payment required then you could set up a tarpit generating trash content or an infinite string of redirects or "read this other page for more info", charging extra for each one.
> you could set up a tarpit generating trash content
and you could call it "EmDash"
So exactly like it is and has been for decades but instead of ads its micropayments
To be frank, I thought this was an elaborate April Fool's joke, particularly when I saw that. It suggested to me 'you could charge for anything' while subtly implying you should also be paying them (within a handy deploy button every few paragraphs) for the privilege of running their stuff on their hosting solution.
I suppose this is the world we live in.
> I don't know how I feel about that
Oh dont worry, I'll do the feelings for the both of us, I have over a decade of experience feeling smugly and validatingly superior to people who save payment info on ipads and then hand it to their kids.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
It's like the exploit from Office Space is finally legal.
Welp, it looks like if you selfhost, the sandboxing of plugins benefit goes out thr window from what I'm reading. What kind of open source is that? Opencore? More like openinsecure, for thr security version, pay the Piper. I might still give it a try, but I sure hope we can put monthly monetary ceiling, had ceilings on our accounts. Anyone knows if cost-caps are possible on CLOUDFLARE??
Also, it looks like there are egress charges to download R2 object storage. So he day we choose to exit stage left, we will be taxed. Wanna setup independent backups for compliance, we will get taxed on egress. Am I reading this right guys??
Honestly, you'll struggle to find a cloud platform cheaper than cloudflare.
The $5/mo gets you 10 million dynamic requests (static assets are not included in this limit, so often a single pageview will be 1 dynamic request) and that would be across the whole workers product for your account, no extra pricing for extra websites, domains, or anything else like you'd see in most "wordpress hosting"
I run all my personal sites and client sites (one of them for a fortune 500 company) in the $5/mo plan, and the only time I went over that was when a client got hammered with malicious requests (and it was like $100)
Disclaimer: I have no relationship to cloudflare, I'm just a happy customer
I run a rust webserver on a €4 VPS from hetzner that serves 300M (million) requests a day. Way cheaper than doing that on _any_ "serverless" request-based platform, I think.
Yes perhaps I should have specified you can't get much cheaper for serverless platforms.
You can certainly run a VPS like that for cheaper, you could probably even beat the raw request numbers from those 1€ a month vps from ovh or similar. The key difference is with cloudflare your site is globally distributed by default, and you get to buy into the whole ecosystem, if you want.
> The key difference is with cloudflare your site is globally distributed by default, and you get to buy into the whole ecosystem, if you want.
The real question nobody asks: do you even really need global distribution?
Most of the time: no
But sometimes you do have clients in both sides of the atlantic and it's nice being able to cut their request times by a few hundred ms "for free". Personally, that's not the main reason I use cloudflare, but it can be handy!
interesting, I'd assumed the lowest tier of hetzner (4.50/m, 2 cpus, 4GB ram) wouldn't hold up to that.
must be very light, for so much traffic. any more details?
Unless someone adds this feature, this is completely uninteresting to me, as well as dishonestly presented by Cloudflare.
I don't think it's the code that makes WordPress valuable. I've been learning WordPress recently and haven't been too impressed with the internals. WordPress is valuable because of the ecosystem and support. I have no doubt that WordPress will still be a thing in ten years. What's the support plan for EmDash? I see commits are mostly from a single developer.
E: Oh, I think it's an April fools joke, I'm embarrassed.
E2: Apparently not a joke.
Cloudflare doesn't do April fools jokes. In fact, 1.1.1.1 was released on April 1st back in 2018 and now it's one of the most used DNS service in the world.
8 years later and now I'm getting the 4 1's joke.
I presume if Elon sets up a CDN, the IP will be 20.20.20.20.
I still don't get it
1.1.1.1 has 4 1’s, as in 4/1, as in April 1 (or so I assume).
I interpreted it back then as just following the tradition of 8.8.8.8, 4.4.4.4, 2.2.2.2
4 1's == 4/1
could just be a coincidence
It's a legit April Fools'.
On the initial commit:
> Some content is hidden
> Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
This for "a spiritual successor to WordPress".
Isn't it normal for the initial commit to be large?
A little larger, a lot of the time, though I like a small initial commit better. Though just a little larger. Not so large that it is too large to show on a GitHub page. That means not using version control properly.
Usually when someone decides to share code with the world, they don't want to publish the actual development history. They publish the first version that is ready to go public as the first commit. With enough functionality etc.
> Not so large that it is too large to show on a GitHub page.
Maybe not applicable in this case, but Github has a ridiculously low threshold for when it starts hiding diffs. Probably a limitation of their new React frontend.
I can assure you this is not an April Fools. Cloudflare does not do that. This is a real project.
I can assure you this is not an April Fools. Cloudflare does not do that.
It should. I miss the days when tech was interesting and fun.
Even Steve Jobs, for all his later-day revisionist hard-assed reputation, enjoyed the occasional Easter egg, inside joke, or April Fool's joke.
I appreciate a good April Fools joke, I also appreciate CloudFlare's approach of "we're extra serious today, here's some useful stuff for ya"
I hated that shit. I'd load Slashdot and there was no real content or it was difficult to find real news amongst all the crap. It's not funny. It's annoying.
Some of the april fools things can be annoying, but I have a big shrug for there being less real news for a day. Anything important will get through and most days don't have much interesting news anyway.
I feel bad for you. That's a lot of anger over virtually nothing.
Would you be annoyed if HN went offline just for the hell of it for a day every year?
But you're right, I was an extremely angry person back then. Many years of therapy and deliberate ongoing work and I'm a radically different man. Thank goodness I got to the other side.
Would you be annoyed if HN went offline just for the hell of it for a day every year?
No. Not even a little. HN is not food. HN is not water. HN is not my family or my job or in any way vital to my life. It's an amusement. A diversion.
I am not a FOMO victim.
There were some years in the 90s and early 2ks that had good april fool's jokes, and that was what bubbled up. Not everyone did, so the novelty also made the "meh" ones seem better. By 2008ish everyone was doing one, and most of them weren't very good. By 2012ish marketing got involved and almost all of them were terrible and unfunny.
It was a nice tradition but, like many things, the scene got too big and corporate. It was a zombie tradition for a while then slowly faded away.
In fact when cloudflare started releasing serious things on 4/1, I found it to be a refreshing subversion of the trope.
Hm, you might want to catch up on the Wordpress “open source” drama with WP.com vs .org, WP engine and Matt.
There might be pie on your face but they stole my line, https://github.com/HatmanStack/kill-wordpress
I think you need to account for the base rate. There's a lot of WordPress plugin vulnerability disclosures because there's a lot of WordPress plugins and there are enough deployments of the plugins to make searching for those vulnerabilities is worthwhile.
That site warns that WordPress plugins can be abandoned, but that's clearly not a WordPress specific issue. Sure some site could use SSG, but that's a different design.
I certainly don't want to claim WordPress security is good, but I'm not sure that site is measuring anything meaningful.
Just measured your visit, zing.
There's always https://textpattern.com/ which is also as old as Wordpress (older?) and better coded. (See also thttps://textpattern.org/ ).
It stores plugins as strings in the database, then pulls those strings back and evals them as PHP on requests.
"Better coded" is very much a subjective assessment.
Thank you very much for sharing your research results!
I really appreciate your work and even more that you took time and risk exposing your findings, I wish more people did this.
Its impressive work from CF that lots of people in this thread are unsure whether its a joke or not, like a delicately balanced april fools for the hn crowd
Oh, come on. It must be a joke. They can't be serious with this sloppy thing.
wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
yes you want a global db handle sure ya lets delete all tables woohoo
If it powers 30-50% of the web, including thousands of major websites, it works at some level.
Ivory tower "just don't use a low-cost solution" people aren't going to hand over money to people to use a higher-cost one, are they?
And ignoring why it's used besides the sloppiness means they have a huge blind spot to what people actually want:
"wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious"
Nothing in this quote doesn't describe very real needs.
> wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
You've sort of nailed it, but this isn't a bad thing. An alternative for these customers does not exist.
There's another vertical which is organizations that have armies of writers churning out content. Any kind of publisher or advertiser, basically. There is no better CMS for this. Large organizations like NYT, etc chose to write their own.
>> wordpress is valuable because it allows very bad developers / marketing people to write very bad code and get away with it, driving extremely low cost solutions for clients who are cost concious.
> You've sort of nailed it, but this isn't a bad thing. An alternative for these customers does not exist.
Yes! I'm locked into WordPress, which I hate, because it's the only platform that will allow a non-developer to maintain it if I get hit by a bus.
I started building sites for clients in the late '90's, and quickly made "client can edit their phone number on all pages" a key requirement. Wordpress with a WYSIWYG page builder solves that — it's not the only solution, but it works pretty close to right out of the box.
Which also allows you to not be on call 24/7.
A decade ago I had to learn and run WordPress for a job. I held my nose up the stink was so bad. But quickly I learned how to manage it and have modern sensible practices around it and I've probably gotten more real value out of it than any other CMS or web framework I've touched. That includes Rails.
Thankfully I don't have to do that anymore, but you can sanely and safely run WordPress today and there's zero shame in it.
There are options that can be run by anyone, but they're often very constrained in what they can do and show.
Wordpress is solidly in that middle ground where you can do a large amount of customization if someone'll pay for it, and then they can do the day-to-day care and feeding of it.
Everything else has either been much worse in all possible ways (Joomla!) or has been a collection of developer wish-lists unusable by anyone (Drupal).
There are better alternatives, for as little as $10 per month. If your clients think such a cost is too much, then you want better clients.
yep. we like it because with shopify or other platforms, you run into limitations. with Wordpress I can literally just whip it into whatever shape i want.
As a (unfortunately) wordpress dev this seems to solve my single biggest painpoint with WP. Which isn't plugin security, but the overall plugin architecture.
WP treats plugins as content, literally in the same top level `wp-content` directory as uploaded images. This makes CI/CD among other things, a nightmare. But EmDash plugins are just TS modules, which has got to make things easier even if plugin configuration does end up in the db somewhere.
Wordpress has no concept of a "staging site" and no way to make changed and then "export" them from dev to production; you basically have to either restore it as a backup or just replay the changes by hand.
Huh? That’s not how i think you should be approaching that. I always run local, staging, and production sites. It’s easy to setup and deploy across.
How do you deploy menu changes from staging to production?
I’m not the one you asked, but when I did WP work a few years ago I would solve it via a hook that was triggered on Jenkins deploy. The hook would always fire and listeners to that hook would execute migration scripts and similar callbacks. For example used it to migrate some tags to categories and vice versa.
https://developer.wordpress.org/plugins/hooks/custom-hooks/
Why would you expect it to? It probably predates these concepts. /s
Serious question: Why is everyone still using JavaScript to AI-code projects? You can vibe-code apps with real languages now.
There's no reason to use an interpreted, bloated, weird language anymore. The only reason interpreted languages were a thing was so you could edit a file and re-run it immediately without a compile step. Compiling is now cheap, and you don't have to build expertise in a new language anymore. Ask AI to write your app in Go, it'll happily comply. Run it and it's faster with less memory use and disk space. The code is simpler and smaller making reviewing easier. Distribution is as easy as "copy the file".
I'll grant you, interpreted languages skip the "portability" compiling/distributing step, and let you avoid the stupid MacOS code signing. But Go is stupid easy to cross-compile, and (afaik?) the user can un-quarantine a self-signed app pretty easily.
> with real languages now.
how is javascript not a real language?
> There's no reason to use an interpreted
there are loads and loads of reasons to use "interpreted" languages. that you can't think of even a single one while still pretending to be knowledgeable in the field is really intriguing.
> bloated, weird language
oh, i see, this is all just a religious rant. carry on!
Typescript is legitimately weird. You start off with Javascript, a language made to validate HTML forms. Then you implement a bytecode compiler so it's not unusably slow and buggy. Then you implement "frameworks" to try to make it create real applications across the insane platform that is the web browser. After twisting yourself into a pretzel just to avoid learning or making a new language, you finally invent another language on top of the first one just so you can have types. To top it all off, it takes up tons of memory and disk space. (I don't mention the slowness because I take it for granted, but 5x-10x slower than Go code is still worth considering)
i'm not a fan of ts either, but can see the appeal for business. of course it is bolted on ... like almost everything on the web, which is a complete frankenstein. but it works, and truth is there is no other alternative yet. otoh it is performant and efficient enough for almost anything these days.
coding in go (or whatever) and transpiling is just an extra step on top of that. not without benefits, mind! there are surely many situations where that is appropriate. but that still doesn't mean it is universally the "right thing". which brings me to:
> just to avoid learning or making a new language
there simply is no "one language to rule them all" nor there ought to be one. my entire career has been about learning different languages, techniques, tools, systems, environments and workflows. lots of them, nearly non stop. javascript has its nice place, and i like it vanilla, in all its weirdness and unapologetic untypedness. :)
Like it or not, it's the only language that'll cross over web backend, web frontend, iOS, Android, TV, Windows, Mac, et al. And with something like tRPC your data being fully end-to-end typesafe too.
The problem with Go specifically is that it's not great for processing arbitrary JSON and especially not your typical frontend code.
One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating.
Another problem is that the type system is often not expressive enough for frontend code. So you either have to generate types or end up with something like map[string]any, which is awkward and gives you less guarantees and support than what dynamic languages typically offer (in other words, dynamic languages are better at being dynamic languages than Go).
Now these problems don't emerge in every web UI based project, but when they do, it's really painful and limiting compared to what one is used to.
> One issue is that you don't write Go code, you write Go plus some templating language (like html/template or go templ). Not being able to seamlessly move from regular code and template code adds friction and is limiting while developing, figuring stuff out and iterating.
Wow that is the cheapest excuse I've heard recently. Templating languages can certainly be dogshit, but demanding it to be the native language is pretty weird. Also it's not like the JS ecosystem spawned their own weird abominations to do simple string concatenation. Sorry for being harsh, I understand that as a general inconvenience but attributing JS as superior is just bold.
I‘m not even a fan of JSX, but it’s simply way more productive than having a separate, idiosynchratic language for templating.
The issue is not an aside or secondary. Web development is a highly competitive profession. I literally cannot afford too much development friction.
There are very strong alternatives to JSX that I prefer btw.
Lit-html builds on JS native template literals, the performance and bundle size is astronomically better.
PHP I wouldn’t recommend anyone, because of the insane footguns, and in recent years it has become increasingly unstable, but if you already know it well, then it has a lot of properties that are missed in other ecosystems.
Clojure does it best from a productivity standpoint if you own the whole stack. The REPL workflow is far ahead of anything else I tried and expressing UI as regular, compact data literals is a unique advantage.
Now I like Go, and I tried it for web development, because I consider it a very high trust language and ecosystem. It just has a few disadvantages in that department when used in the trenches.
a) llms are good at writing typescript
b) typescript fixed a lot about javascript and is somewhat decent
c) multiple fast and performant runtime engines
d) deployment story is php levels of easy
that's it.
> d) deployment story is php levels of easy
Yeah just invalidate the SSR cluster for your tiny footer update and let it prewarm until coffee break. Easy.
Yeah, my theory is that Rust is going to be a somewhat "local optima" for a while for LLMs.
LLMs have a couple major problem, they hallucinate and make mistakes. So the ideal way to use them is to constrain them as much as possible with formal methods. Rust's type system is a formal proof of some forms of correctness, this will let "vibe-coding" work to a much higher degree than with other languages.
In the very long run, I suspect that all vibe-coding will actually occur in a language with dependent types and we'll push as much as possible into being proven correct at compile-time. Since the cost of generating code is plummeting, and thus the sheer volume of code will be exponentially rising, this is the only way to prevent an unsurmountable mountain of errors.
Formal methods and LLMs are a match made in heaven.
Most coders are familiar with javascript. Javascript has the largest community. If you want to be popular, then JS or rather TS it is.
But it's correct that it is odd. As long the lang is mainstream enough, it hardly matters. My assumption is that JS/TS coders have the highest resistance to switch platforms, the ecosystem is huge, it's cross BE/FE, performance isn't complete trash, everyone they know knows the platform as well. Why switch? It's a screwdriver, if your passion is to screw things, you will.
Because of the runtimes (v8), I believe.
Do LLM's not benefit from the abstractions higher level languages like Javascript/node offer?
Perhaps I'm speaking out of depth because I haven't done a lot of Golang, but I've always thought of it as a systems language first, which means by necessity you have you to handle lower level problems yourself. I'm sure there's plenty of libraries that paper over this - but the philosophy of the languages themselves is different. Javascript was designed to solve CRUD like interfaces/problems quite well.
Maybe this is just an outdated argument though that isn't really relevant with modern golang/rust though.
You can implement apps in any popular language you want with modern LLMs (they still need to be trained on that language). Tell it what to write and it'll do it. But the downside is, if the language is a memory hog or takes up tons of disk space, you're not gaining anything. If you don't have to manually write the code yourself, you might as well pick a language that has the fewest problems when executed.
Go has a really solid standard library which removes a lot of what you'd typically implement separately. You don't solve lower level problems because the language already solved it. Nodejs has the opposite issue, where there's virtually nothing standard, so people made libraries to implement 5 lines of code. Rust also has a minimal standard library, and is more complex than Go. If you want a dead-simple, batteries-included compiled programming language, Go is pretty much it. Since you write less code with Go, there's less context use, so actually, the LLM has an easier time with Go apps.
It started as a 'systems language' but it has many projects that extend its usefulness. There are two separate frameworks that let you write one Go app and compile it as an Android app, iOS app, Mac app, Windows app, Linux app, both GUI and console. It has multiple web frameworks, and one is even an Electron replacement. The thing it doesn't have is a REPL.
A WordPress spiritual successor backed by Cloudflare sounds great in theory, but the headline feature, plugin isolation via Dynamic Workers, only works on Cloudflare's runtime. On any other host it's just a TypeScript CMS without the security model that justifies its existence. Open source but architecturally locked in.
I missed this. So they didn’t really solve much at all. I guess at least it’s compatible with other runtimes. But yeah, who would’ve guessed that Cloudflare software would (besides being vibeslop) prefer Cloudflare infra. This, of course, makes the software quite hard to adopt.
Workerd (the platform for Workers) is open source though? You could run your own? And people do run their own, at least according to Cloudflare.
Open source runtime, not the orchestration layer on top.
Are you saying that by providing a globally available service, they're engaging in vendor lock-in, because otherwise you'd have to build your own globally available and distributed service...? ...yeah?
But if you wanted to run Workerd on EC2 or Google Cloud or whatever, you could...so not really sure how that applies here.
You cannot say you’re the spiritual successor to WordPress, if your software doesn’t support running plugins out of the box on arbitrary installs. WordPress is very easy to host and scale, you only need a basic server and a CDN. A spiritual successor would follow that and also have all the new shiny stuff.
> Open source but architecturally locked in.
You hit the nail on the head.
Cloudflare's new business model is to find popular OSS projects, create a vibe coded alternative that only runs on Cloudflare's infrastructure.
Sadly, it looks more and more like it. It’s sad, because they were doing wonderful stuff.
Agreed. They are destroying their professional reputation.
I think pretty much every corporation that can have had this thought, has had it. Really "any popular software" where they can provide similar functionality. And I think this is going to happen more often before it becomes less common.
Maybe other runtimes should copy dynamic workers.
> While EmDash aims to be compatible with WordPress functionality, no WordPress code was used to create EmDash. That allows us to license the open source project under the more permissive MIT license.
Ha ha, that's really funny timing given the recent launch of Cleanroom As A Service, promising that you can licensewash other peoples' code quickly and easily: https://malus.sh/
I'm not saying they did that, but it's ironic timing.
Malus is (well crafted) satire.
So well crafted in-fact, that if you pay them, they will provide the service.
https://fosdem.org/2026/schedule/event/SUVS7G-lets_end_open_...
An edge-first CMS is cool. I've wanted something that works well alongside Astro for ages.
That said, WordPress is a weird paradigm to be replicating in 2026. WP won on extensibility, but the actual legacy of that ecosystem is bloat, security disasters and dogshit performance.
What I think makes more sense is this kind of edge backend paired with a proper modern authoring experience with visual control like Framer/Webflow with Notion-style database primitives underneath.
And given how fast AI is getting at generating bespoke business logic, building another monolithic plugin ecosystem feels like solving the wrong problem.
Plugins were a workaround for the fact that most people couldn't write code. That's increasingly not true.
> Solving scale-to-zero for WordPress hosting platforms > WordPress is not serverless
Just not accurate. WordPress doesn't prevent this.. It's up to hosting providers to work on their infra so it can run in a serverless fashion.
For example: https://www.agiler.io
That's serverless wordpress that scales to zero.. no changes to WordPress, plugins or anything else.. just platform infra.
Last time I checked Wordpress was completely fine living in a couple of PHP files on a webspace. That’s like the pinnacle of „serverless“, is it not?
mysql/mariadb and the shared filesystem requirements are a bit different than what lambda/etc provides. So not really, but it's all solvable clearly.
Not even a little bit.
So this is just a "similar" CMS to WordPress in that it has themes and plugins, and you can publish pages, posts, tags, categories, etc. But there are lots of similar CMS out there, and this one isn't "compatible" with WordPress since you obviously can't just take a WordPress theme or plugin and install it in your EmDash site. So I don't even know why the focus on WordPress here - this is just yet another CMS that offers similar features.
WordPress is the most popular CMS, and, at any moment in time, especially lately, there are a lot of people looking for a "WP alternative". I agree that it's not actually compatible, but it seems they tried to make it similar just enough to be able to use the word without 100% lying and attract people that way.
Nobody is looking for wp alternatives, if they were they would have moved long ago, as there are tens of similar CMS's that were supposed to be much "better" on paper yet never took of like octobercms,gravcms,ghost,netlify,wagtails,etc
IMO unlike WP, EmDash can he harder to host.
With WP you can find a plethora of cheap PHP hostings that offer WP preinstalled. If you need to tweak a theme - just download a .php file via FTP, tweak it and upload back.
No server management or restart is required.
One big potential benefit that EmDash has - every WP deployment is basically a honeypot.
It looks like I'm in the minority after reading this comments, but I'm quite happy to see this announcement.
A "good" standard, free CMS with theming and plugin support without the issues of Wordpress is _welcome_. (And the issues are many: Licensing, trust, drama, security, and cost).
I'm guessing that a lot of cynicism here is coming from this crowd not being the target market of Wordpress in the first place? What were you recommending to non-technical friends and family who wanted a good, open source, affordable CMS to back their website? Wordpress has all the right _ideas_, but the wrong implementation.
There are great standard CMSes that do everything technically better than Wordpress (not that it's harder to jump higher than a rock, but hey). That's not the hard part. Every developer should build a good CMS once.
The hard part is displacing Wordpress market share; building a community of bloggers, marketeers, agencies, web designers, and so on; creating a huge ecosystem of paid and free plugins, allowing plugin devs to commit to your marketplace and lock customers in.
Wordpress is awful. The only thing it's got going is its moat, but that's not an engineering problem, but a people problem instead.
Those standard CMSs that are technically "better" than WP, I would bet they are at least over a decade old, some have even come out during the same time with wp when there was no market share to speak of and still were left in the dust.
The problem is that people misunderstand why WP was and is better than all alternatives that tried to take it's place, I have no idea either but I know that others have tried same thing as CF and failed.
I have been one of the maintainers of a moderately successful CMS back in the day, but there are definitely well-groomed alternatives that have popped up a lot more recently than that, especially from the headless variety.
I'm convinced the thing that WP did better was being the first simple and accessible blogging platform when blogging was still a thing. IIRC, the alternatives were things like Joomla or Drupal - awful behemoths for enterprise users. WordPress was a breath of fresh air compared to those, and out of the blogging scene, people started to use it for agency projects, while others published an ever-increasing number of plugins and themes. The rest is just momentum of that movement.
I find it hard to believe that people used to WordPress, with its flaws and virtues(yes, wordpress have virtues), will switch to this, no matter how much it's from Cloudflare.
> There are great standard CMSes that do everything technically better than Wordpress
Like?
I think the cynicism is related to cloudflares recent previous releases that were considered to be slop that significantly overpromised on its capabilities/completeness. Trust can take a long time to rebuild.
Throw in the the bragging about slop and cleanroom clones to avoid AGPL, the name and April 1st launch date, and maybe the high priority afforded to agent-friendly crypto payment infrastructure if anyone was paying attention. Maybe they prompted the marketing agent with "how can you get HN to loathe a product as innocuous as an open source headless CMS?"
Other than that, it seems it might be a half decent headless CMS, if the bit of WordPress you want is its interface, and not the number of plugins and devs and not being tied to Cloudflare's infrastructure.
> I'm guessing that a lot of cynicism here is coming from
...the fact that CF just dumps tokens to generate some slop to compete with the single biggest web platform and casually adding a vendor lock in. It's just buzz, an inexpensive attempt to grab a valuable market share.
If you set security as a selling point for EmDash, then I am baffled. The WP lock file has 30k lines, the brand new EmDash has 16k lines, but it LESS verbose yaml. JS is the cornerstone of anti-security that WP couldn't dare to compete with. The plugin isolation is also bogus, WP plugins are insecure because they have all access to everything, but they need at least some, mostly DB, how is that even solved? Isolation does shit there.
I am not a fan of WP, but CF doesn't even try to get this right.
Frankly, you're wrong. This is a fundamentally better plugin architecture that WP, and if you can't see it, then it's your understanding of security that's not right.
If you have arguments, then make them. This is just saying stuff for the sake of it.
The post literally does that. it talks about how plugin access to core is handled. So to be explicit: if you don't see that as a very significant security improvement over WP's open world, then it may help to understand why. The post also talks about WP ecosystem downside due to this.
Surreal CMS. Nothing is more simple and robust for non-technical people to use. Not open source, but that's never a requirement in these cases.
Default EmDash size: 483Mb. Default WordPress size: 70Mb. That's progress?
I can't believe as developers we were worried about AI training on licensed code. It turns out it didn't matter at all. You can just point an LLM at some source code and you're off scot-free.
Almost all apps are just CRUD. The code is not that interesting. The valuable IP is the product.
In what way? Does it matter that there's an Adobe logo on the top if I can just point an LLM at some leaked code and get PictureStore?
This is naive thinking you can just rewrite WordPress and think it's going to solve any problems that exist with WordPress. The entire community of WordPress has been built over decades including its successes and failures, but people are not going to just stop using WordPress as I have seen people attempt this over and over in the last 20 years with little success.
In my view, Astro is the most reasonable choice for a blog-like website these days. All the simplicity and all the capabilities that you need. Excited to check this out and see what they have added on top of it.
Why not a templating language, like Nunjucks EJS or JSX, with vanilla JS for interactivity?
You can use JSX in Astro if you prefer, but a CMS is more than just templates (not a LOT more I'd agree considering it's still static).
I know you can, but do blog-like sites really Island architecture?
IMO most sites like that would be better to pick no-framework, vanilla or jQuery for interactivity.
I can't image average WP users would be happy to move to EmDash, only to have a constant stream of dependabot updates for Astro.
It has 55 direct (non-dev) dependencies https://www.npmjs.com/package/astro?activeTab=dependencies - while ejs has 0 and nunjucks has 3.
I'm weary of updates, maybe it's just me, but I doubt it.
After all these cases like axios it's definitely reasonable. But many people already use Astro. And with static website there are far fewer attack surfaces compared to a full-on PHP running WordPress on a VPS.
> no WordPress code was used to create EmDash.
Oh, neat. Which model wasn't trained on WordPress?
I don't like that they see the main selling point that the license, is not GPL, and that plugins don't have to license it that way either. I understand that not all developers are comfortable with the GPL license, but it allows to the code continue to be open source and that most plugins are open source also
A big issue with WordPress is the GPL. There hasn't been much clarity about it and the interpretations I've heard from Automattic in regard to which code is and is not covered by the GPL come from Automattic, not from the GPL. https://redsweater.com/blog/825/getting-pretty-lonely
For what it's worth: they live up to their own standards. Here, for example, is the source code that powers their VIP platform product:
https://github.com/Automattic/vip-go-mu-plugins
It must be open sourced because it's based on WordPress. I still love that.
It's a shame they don't seem to try to address the divide between CMS's and static sites.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
I've been migrating a few Wordpress sites from Wordpress to Astro + Strapi recently, working in 'hybrid mode' so the entire site is static except for post previews in Strapi (only that one route is SSR).
Editing content in Strapi, once customized with CKEditor and such, is Wordpressy enough for the human Editors familiar with WP.
So far I'm loving the stack.
EmDash with some aggressive caching and SWR is effectively this, and we're getting closer to that every day. When the cost of maintaining the data part of the CMS is effectively free, you're basically working with a static site anyway.
I haven’t used Wordpress for a few years. But with WP Super Cache (1) we also always did pretty much that: On saving a post/page the static HTML would be written to a cache directory and be the default content served to visitors.
[1] https://wordpress.org/plugins/wp-super-cache/
The issue with static sites is they can't do comments.
Astro would call that an island: https://docs.astro.build/en/concepts/islands/
I guess this is our answer to the question of why Cloudflare acquired it in the first place.
Isn’t that just the way old school Perl/ruby/php web apps from 20 years ago did things but with a fancy name?
I bet 99.9% of live Wordpress sites no longer have comments enabled.
So many WordPress sites don't have comments.
They can - it’s just more complex.
You just put the comments into something like firebase/supabase etc or use one of many off the shelf solutions. Free tier is fine.
Is it still a static site then?
You could just do it with CGI scripts, without the external dependencies, but that isn't really static either.
Depends what you would call that architecture then I guess!
I run my local theatre website by writing the posts in markdown, and then have some github actions which use Hugo to turn it in to a static site and then uploads the content to an S3 bucket. The site itself has dynamic content like within-website ticket buying from eventbrite and a contact form that sends email using an external service. It also calls in things like google analytics.
Does this still count as static? Personally I think so, Even though there are 'dynamic' elements.
IMO static refers more about how the content is served rather than saying that the content can’t be ‘dynamic’ as lots of Wordpress sites have static/non interactive content but still regenerate the html on each page load.
I run static sites for my clients, with embedded forms.
Performance says they’re definitely still static sites!
"Just" sure is doing a lot of heavy lifting in this sentence.
I don't even think the WordPress editor is very nice. It's completely separated from how the actual results look. There are CMSs which lets you edit directly in the web page exactly as it will look when published.
As do most productivity software, like MS Office, Photoshop, Apple's iWork, etc.
Imagine making a document in Word, and it looks completely different when published.
It is written in typescript not php - so not a successor of WordPress. Typescript is a complete other Story. With compile step and build Pipeline. All not necessary in php
Compile step? Your knowledge is outdated.
It's great that they are recreating much of the fundamental software stack using LLMs. But if you're going to 'vibeslop,' at least do it in a language other than JavaScript.
I struggle to understand why anyone would want to generate code in TypeScript - unless what you're building truly can't be done in Go, Rust, or Kotlin; anything but JS.
I’m not sure how much of an improvement it really is to rewrite something from PHP to TypeScript while claiming security benefits.
"solve security" - that's an April Fools joke if I ever heard one.
Given how shitty it looks and behaves, I was 100% sure this was an April Fools. But after reading the serious comments here on HN, I'm not sure anymore...
You can certainly solve WordPress well-known security issues by dropping WordPress, hard to argue with that.
I dunno, with the constant firehose of debate and disdain for AI this is a joke I'm too burned out about to feel like laughing at.
I predict that almost no existing WordPress installs will be ported to this
Spiritually hollow; at this point, it reads more like marketing material than anything of genuine substance.
Yeah, they are churning out these AI slop projects for blogpost hits about once a week now
Security by reducing attack surface is underrated as a design philosophy. We took a similar approach for a PDF tool — moved processing client-side entirely so there's no server to compromise in the first place.
I used to host a wordpress on my server for some people who configured it. However, when some bots got there, I was unable to keep them at bay. I upgraded WP's version, but the Wordpress had some vulnerable plugin, and I was unable to find out what path did the attack go. I only could find that the malicious files were uploaded into images/ directory and run from there. That's something I blame PHP for (and of course my lousy LAMP configuration skill, but the directory was not allowed to run the code from, I must impress). I tried also to block IPs attacking my server, but this was like cutting one of the hydra's heads.
So, long story short I ended up removing write permission to all the folders, thus disabling upload, and later they went to another server. They host it fine there, I still maintain redirection from the main domain to their host. However I failed, but really this is sad the WP is so vulnerable just by the plugins installation.
Since then I am looking for WP replacement that would not mix up the code and the images from the upload directory (presumably in rust or golang), but this would need to be opensource anyways.
Will you look at it. Another Wordpress “killer”. Wordpress has that market share because it can be easily installed in a wide variety of servers and because of its plugin ecosystem of dozens of thousands of plugins and huge flexibility/customizability. Wordpress is one of the most flexible pieces of software out there and none of the competition seem to get why Wordpress is so popular.
this won't go far
base platform used - typescript - means for the average Joe out there - deploying is difficult - compared to php.
if they really wanted to be revolutionary - they would've made a single PHP script either on FrankenPHP backed by sqlite - single file deploy - with yeah a permission model Ala denojs for the security aspects.
end of day this is vibeslop.
Its kind of annoying that CF would use an LLM to build something and try to pass it off as something built from "the ground up". Its just copying the library that was already build and passing it off as their own.
But isn't this a well-curated April Fools?
Serious question: Who actually builds stuff on Cloudflare workers? I mean large software projects / services, and not just side projects where the ability to scale-to-zero is perhaps more important than the scale-to-infinity direction. I feel like Cloudflare keeps pushing workers with its full force yet I fail to see the appeal.
I'm building a commercial SaaS product on Workers. Although I've barely scratched the surface of what Cloudflare offers¹, so far it's been great. The value proposition is effectively the same as serverless in general: You worry about the product, they worry about deployment. Note that Cloudflare Workers is just one (albeit important) star in their constellation of capabilities.
¹https://developers.cloudflare.com/directory/?product-group=D...
Cloudflare Workers solves their "scaling the price to infinity" problem.
Me. I used to deploy everything via Docker swarm but recently migrated everything to workers because wrangler is awesome, it makes blue/green very simple, and it's a lot less of a headache for me to maintain in general. It's a great/flexible product. I also use R1/R2 pretty extensively.
Anything built in Svelte can be deployed to workers easily, and it’s a very good platform.
Just missing compartmentalisation features between prod and dev environments.
It's always seemed like a solution looking for a problem.
It's kind of ironic that the name of this product is also the most obvious marker of LLM generated content
That's the joke.
Oh I am slow lol
Is this an April fools?
Name is a joke, but the project is real
Functional April Fools, the best kind. A couple years ago Eleiko, a weightlifting equipment company did one, the 'Heavy Mug', a 19 poundish steel coffee cup with a handle in the style of a knurled bar, and actually did a limited run of them.
"That allows us to license the open source project under the more permissive MIT license."
> But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
> no WordPress code was used to create EmDash
Hm. Do you think those agents were trained on WP code?
Isn't it kinda bad taste to call your thing a "spiritual successor" to something that is very much alive?
I'd usually expect this to be used about something like Google Reader, not something you are actively competing with.
A quote from their nextjs writeup but I like:
> Most abstractions in software exist because humans need help...It's not clear yet which abstractions are truly foundational and which ones were just crutches for human cognition... We took an API contract, a build tool, and an AI model, and the AI wrote everything in between.
The thing that has always stood out to me about WordPress, is that you can get a site up without any of the usual technical steps I associate with creating a site, but still have access to the innards of the site. Does it often go wrong, sure, but it is a lot more approachable for less technical users.
In contrast, typical web frameworks (even static sites) require a code change, build, deploy, etc to update many aspects of a site.
The power of WordPress is not the ease of use, but PHP.
Anything built on PHP will be widely used, like Laravel
That used to be a major selling point because hosts enabled PHP for a directory devs would FTP things into, but those days are thankfully long gone. I don't think it's any more difficult to host a JS, TS, or anything else, app than it is to host a PHP app today. In fact, PHP is probably more difficult than something like Netlify.
That’s also nice joke! You are all killing it today
With PHP you can still drop a single file on shared hosting and be up in minutes, with no build step or CDN proxy in the mix.
npm deps adds plenty of attack surface on its own. Netlify is fine until you need custom binaries or persistent storage, then it gets weird fast. PHP has plenty of warts, but the ops path stays flatter than Node for the boring case most sites need.
> With PHP you can still drop a single file on shared hosting and be up in minutes, with no build step or CDN proxy in the mix.
I don't have a shared hosting account any more, nor do I want to have to figure out which providers are the best for my needs.
It's far quicker for me to upload something to Cloudflare Pages or Netlify.
Well, you’re quite fucking wrong there.
All PHP is going to be replaced with single binary Rust apps.
Talented teams will build the atoms for most apps - blogs, CMSes, ticket systems, forums - and it'll be easy for end users to configure.
Rust is easy to code gen and deploy now. No barrier to understanding lifetimes. It's the language everyone should be using Claude Code to emit.
Everyone is now a Rust engineer with 10 years of experience. (I'm not joking, just in case that needs clarification.)
If you haven't tried writing a simple web service in Axum or Actix plus SQLx, you need to give it a try. You'll be amazed at how simple it is, and you'll be even more amazed at how performant and easy it is to work with.
You do not need to know Rust or have any prior Rust experience. You'll pick it up along the way. It's easy and you'll learn it fast.
Rust is a low-defect rate language to serialize to. The syntax begs you to handle errors, nulls, exceptional conditions within the language itself. This is naturally a good fit for most business problems. It doesn't hurt that the language is fast as hell and super portable either.
If the job is now encoding business logic - this is the optimal serialization that I'm aware of. I write Go, Java, Python, TypeScript, PHP, Swift - I can't think of any better language for greenfield projects that don't have existing language/library requirements.
I'm not sure you appreciate why PHP was successful. You might be completely right about all this, but the LAMP-stack "just upload this file to shared hosting" workflow is what made apps like WordPress win out, and the barrier remains significantly higher to do the equivalent with Rust.
Historically successful.
Draging a bunch of PHP files onto an FTP client is harder than modern dev practices.
If you've got a modern frontend of any kind, you're already beyond this.
Having to compile makes it a pain in the ass to develop with vs php. No existing WordPress dev would ever willingly make that choice
These april fools jokes keep getting lazier every year.
Typescript, isolates, Cloudflare dynamic workers, serverless. You've already lost the market WordPress serves.
I have a love/hate relationship with WordPress. I prefer it over any other CMS for reasons I can't fully explain. Probably nostalgia. I love the editor, the sidebar, the ability to find niche plugins in an endless marketplace, and how easy it is to get a site running.
What I don't love is how insecure it is. You're entirely dependent on plugins (if you're not a developer), and if WordPress updates and a plugin goes inactive, you're sitting on a vulnerability. It adds real stress for something that's just supposed to be a fun personal site.
I stopped building on it two years ago, even though I still like it more than Webflow and most alternatives I've tried. It's a bit sad.
Yes definitely compare it multiple times to WordPress and nobody will think of calling their lawyers.
Is this April fools? With real products launching on this date you can't really be too sure.
Not an April fools joke. [0]
[0] https://github.com/emdash-cms/emdash
That makes it look more like an April fools joke. All the commits are from today.
Cloudflare specifically launches things on April 1st a lot of times. https://x.com/Cloudflare/status/1907055975057506793
They announced 1.1.1.1 on April 1st way back in 2018 too.
Gmail was also launched on April 1st. The fact that it came with 1GB of storage instead of Hotmail, which limited you to something like 20MB, made people think it was an April Fool's joke.
That's not unusual though, large companies releasing something open source very often squash the history at launch.
The best jokes are serious.
> Yes definitely compare it multiple times to WordPress and nobody will think of calling their lawyers.
It's not illegal to make product comparisons. That's just competition.
Tell that to the guy who got upset with WP Engine. EmDash is clearly "inspired" by WordPress including in its UI, so there's definitely something to it.
The phrase "spiritual successor to WordPress" is not likely to be judged a trademark violation, though. It doesn't create confusion in the marketplace as to whether Emdash is WordPress.
The problem with WP Engine was that the name is confusing to users who aren't familiar with it. Presumably the WordPress Engine is the core of Wordpress? Or it's the thing powering Wordpress? It's easy to see ways in which an end user could be confused which was which.
Conversely, this product is called something else, and while their blog post references Wordpress repeatedly it's in a way as to make it very clear that this is not that.
Matt seemed pretty fine with the name for at least 14 years, including investing in them at one point.
>> It's not illegal to make product comparisons. That's just competition.
> Tell that to the guy who got upset with WP Engine.
Why? That situation had nothing to do with comparisons.
I'd really love to see Matt go after CloudFlare over the trademark. WPE might grind him into the dust, but CF will obliterate every constituent atom.
Matt got upset because they forked his open source project and built a hundred million dollar revenue business on top of it without contributing anything back to WordPress.
He'd have more of a leg to stand on if WordPress wasn't itself a fork of an open source project.
Matt should have built something open core or fair source licensed - free for customers, but stops competitors from stealing your lunch. He has no legal ground to argue his case now.
It's a much bigger deal with hyperscalers poaching and stealing, like AWS and GCP ripping off and stealing most of the revenue from Redis and Elasticsearch. That's dishonest and evil in my mind.
Totally orthogonal to this issue of marketing comparisons.
WPE never forked a thing. They were a successful company after he backed out of an investment with them, he resented the success, blackmailed them for 8% of their top-line revenue, then threw a tantrum when they told him to pound sand.
the plugin security problem in WordPress was never really a code quality problem - it was a trust model problem. any developer could publish a plugin and any site owner could install it with one click, with no vetting layer in between. TypeScript and serverless doesn't change that dynamic unless the trust model changes too. curious how EmDash handles third-party plugin permissions at the API boundary.
It runs each sandboxed plugin inside its own dynamic worker, with a separate bridge worker to enforce permissions. The worker only has access to its permitted APIs.
the bridge worker as permission enforcement is a solid pattern - the plugin can't escalate by calling APIs directly, everything goes through the bridge. the edge case I'd be curious about is plugin-to-plugin interaction. if two plugins share state through a permitted API, does the bridge enforce granular enough boundaries there, or does the trust model flatten at that layer?
If creating OSS is this low effort, the right question is: What high effort assets, that are valuable to other builders, should open communities be working on? And I think the answer is open source models with open training and open training data.
I'm all for creating new frameworks that are faster and more secure. But I don't see how this one relates to Wordpress (not in PHP, serverless, not "plug and play", dependent on Astro, "AI Native"…).
It looks like a good open source project, but just call it a new CMS. I think calling it a "spiritual successor to WordPress" is just to gain some marketing points.
Does it bother anyone else that the capability tags in their example seem to follow different noun:verb conventions?
Now that you mention it.. List of capabilities:
Also:> ### Trusted Mode
> Trusted plugins are npm packages or local files added in `astro.config.mjs`. They run in-process with your Astro site.
> - *Capabilities are documentation only.* Declaring `["read:content"]` documents intent but isn't enforced — the plugin has full process access.
> - Only install from sources you trust. A malicious trusted plugin has the same access as your application code.
I don't like where any of this is going
Ine thing no other CMS tends to get right (for my needs) is Gutenberg. Tiptap, mantine etc.are just no substitute and for someone like me with next to no frontend knowledge Gutenberg was the only option that provided the flexibility and good defaults to keep a decent looking website that my students could also post on with no training.
A while ago I ran claude code in a custom loop (calling it autoclaude; this was last summer) to create a CMS with Gutenberg’s editor but a lean Python backend (github.com/hessammehr/nuCMS). This was in the Sonnet 3.7 days and even that model got quite far.
Wouldn't a spiritual successor use the same kind of license? (GPL)
Reading the comments below, have we all fallen for a 1st April Fools' joke?
Actually, rebuilding WordPress without the ecosystem is kind of the point. For example, would Divi or the major page builders rebuild their entire products to support this? I doubt it
Do you think the Wordpress guy is going to have more public meltdowns on this post?
This part is interesting:
"Plugin security is the root of this problem. Marketplace businesses provide trust when parties otherwise cannot easily trust each other. In the case of the WordPress marketplace, the plugin security risk is so large and probable that many of your customers can only reasonably trust your plugin via the marketplace. But in order to be part of the marketplace your code must be licensed in a way that forces you to give it away for free everywhere other than that marketplace. You are locked in."
There was much drama with wordpress some time ago and the plugin marketplace.
i have been a admirer of wordpress plugin system and had been shouting for modern alternative with explicit capability model for sometime. I also have been building own composable app platform (not cms) and this looks kinda great actually.
https://github.com/blue-monads/potatoverse
Cool idea, especially the plugin security angle, but WordPress’s real strength is its ecosystem. That’s going to be hard to replicate.
Curious about the architectural choice: Why not build it as a pure headless CMS separate from Astro, and then ship an Astro adapter alongside it?
The UI doesn't seem geared to power users. E.g. Why is the featured image taking up so much space above the content editing area when it's sized appropriately for the sidebar? Imagine you need to update the text of several posts... Well, now you gotta scroll down half the page to the content area of each one.
And all that padding gets you quite the narrow content area. Not to mention it looks like a very basic TinyMCE. Seems like more of a POC than an actual "spiritual successor".
The generous take is that this is someone's pet project that marketing got too excited about, and that the leadership haven't applied their minds to. GPL provides a moat for the community, who are contributing their time and energy into a project. It ensures that, even if a commercial company grabs your software, extends it, and commercializes it, that you can fold those improvements back into your original distribution. While the commercial entity benefits from your free labor, you benefit back from theirs.
Re-implementing WordPress (their words, not mine) as MIT licensed, while legally questionable, breaks that virtuous cycle and removes the community's moat. They've taken WordPress's roles and menus and borrowed its Gutenberg code (which is GPL), and launched it as an MIT licensed product, which breaks that virtuous cycle. It means e.g. a hosting company can take the product closed source if they want to, and never have to contribute any of what they build on top of the community's work, back to the community.
https://github.com/emdash-cms/emdash/tree/main/packages/core... says "The core EmDash CMS package - an Astro-native, agent-portable reimplementation of WordPress."
Emdash uses WP's RBAC roles. Also uses their menus. Also depends on @wordpress/block-serialization-default-parser which I think might (??) be able to be used by an MIT project even though WordPress is GPL.
They used Claude Code it seems because the first commit has a CLAUDE.md file which became an AGENTS.md.
If I could smash a button and get a 1:1 copy of my existing site, I’d do it in a heartbeat. I don’t see that happening just yet due to the integrated forum software and its own plugins.
With Cloudflare behind it, hopefully plugin vendors will start paying attention.
So it’s a WordPress successor that doesn’t support any WordPress plugins (since they’re written in PHP and this is written in TypeScript) and has baked-in support for blockchain payments. and also it’s “AI Native”, because the internet definitely needs more AI slop blogs.
This IS an April Fools joke, whether or not they intended it to be one.
They say it was developed by AI agents but they still claim copyright in the LICENSE file. Doesn't seem right.
I mean the creator of the commit takes authorship, just like the auto-complete in old style IDE. Using agents requires a skill, that varies from vibe to advanced.
Why do you feel it's not right?
Who wants to vibe code an open source Cloudflare?
If you need a reliable source for WordPress plugins, check out https://github.com/fairpm/fair-plugin?tab=readme-ov-file#fai...
A system for using Federated and Independent Repositories in WordPress
Why would I want to publish my writing online when it can just be copied by an AI?
“EmDash” sounds like it will also generate the writing.
I have long wanted a static blog with a backend content manager that runs serverless. Love seeing this, but we will see if Cloudflare maintains it in the long run.
I've been wanting a CMS on top of Cloudflare workers for a while, so I hope this pays off!
Payload can be deployed to Cloudflare Workers: https://github.com/payloadcms/payload/tree/main/templates/wi...
Pages is a thin layer over Workers, and a standard deployment target for most if not all that I've seen.
This is really buggy and janky… try it in mobile, the navigation doesn’t even work. UX elements move around the place when you hover or click them.
I really hope Cloudflare is ready and willing to stand by this thing for the next 20 years, and drive it as a first class product with a huge open source team. Because short of that you can just add this to the mile-long list of "successors to WordPress" we've been through over the decades. Maybe they're in it for the long haul. We'll see. But it takes time, and mountains of integrations and acceptance into the wider web authoring ecosystem for anything like this to gain real adoption.
One thing that makes it different this time is that coding agents will probably make it easy to port the most important plugins to the new system.
Also, there are successful alternatives to Wordpress too, so the most likely outcome is that it becomes yet another alternative.
This is great, but if the plugin ecosystem isn't compatible will it take off?
Most WordPress users use at least one plugin: it is the appeal of the product.
Good one, at last, April fools joke with some effort.
No thanks, I hate it.
(To be clear, I'm no fan of WordPress either, and its security hassles are a real issue. But some sloppified MegaCorp vibecoded fever dream will never be a suitable replacement, of that I guarantee.)
Is that based on anything concrete or are you just going off of vibes for that?
Thanks, but I'll stick to WordPress.
The plugin security model in WordPress has been the elephant in the room for years. Any plugin can execute arbitrary PHP — there's no sandboxing, no permission system, nothing. It's wild that we accepted this for so long.
The Cloudflare Workers approach (V8 isolates) is fundamentally better because it enforces boundaries at the runtime level rather than relying on developer goodwill. Curious to see how they handle the migration path for existing WP sites though — that's where projects like this usually die.
I am not fluent in Cloudflare-lingo. What is "Dynamic Worker" and how can I run it outside Cloudflare?
The repo says "depends on Dynamic Workers ... Dynamic Workers are currently only available on paid accounts" but the article says "but you can run it on your own hardware".
Lately Cloudflare is trying to create alternatives to big ones, like first Vercel & now Wordpress.
I mean it's cool your created a new CMS and all, but beyond the look of the admin interface and publishing flow, I don't see how this is a "Spirtual Successor" to WordPress at all.
Its a CMS, designed from scratch, for a serverless world. It has a stricter, well defined API that plugins are forced to use instead of directly calling/overriding core functionality like in WP. But that benefit comes with a CMS that's built on top of, and seems to prefer, a ton of CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things).
The web need less consolidation on CF, not more.
> Its a CMS, designed from scratch…
Maybe not scratch scratch: "And under the hood, EmDash is powered by Astro…"
> It's built on top of, and seems to perfer you use CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things.
D1 is SQLite, R2 is S3, and there are other ways to securely run plugins. If it was designed to only be possible to deploy on Cloudflare, they didn't do a very good job.
Plugin security is one thing. Plugin budget is another thing... much larger of a problem in some cases.
Convince me this isn’t vibeslop.
If Cloudflare really have radically changed their software development philosophy lately, this would actually be an interesting project, being based on Astro and coming with some APIs for programmatic management.
Them being so happy about the „cost of software development“ and not going very deep into ecosystem, community or project management doesn’t convince me that this is going to be a worthwhile project, even if, unlike their previous vibe coding demos, this one actually works.
I'm the main engineer on this. I've also been on the Astro core team for two years, so I do think I understand real open source software and community.
As the post implies, I did use a lot of agent time on this, but this isn't a vibe-coded weekend project. I've been working full time on this since mid-January.
Could you say a few things on your plans to develop the community and ecosystem then as requested?
That's the significant part of Wordpress after all, not the mediocre code.
I think one of the reasons people think this is slop is because of the name. How does the name EmDash relate to being a wordpress spiritual successor? It's clear the name was chosen as it relates to the use of em dashes in AI generated text, so why would you want to be associated with that? Why not choose a name like Astro Press given your experience on Astro?
Not sure why you’re being downvoted. The name is so bad. WordPress is a great name for normies. Something like Cloudflare Press would make more sense. EmDash is at best a temporary meme.
> It's clear the name was chosen as it relates to the use of em dashes in AI generated text
this is not clear to me, and is not discussed in the article
you can like or dislike the name. but criticizing the quality of work based on your affinity for the name is foolishness
It doesn’t need to be said in the article, it’s obvious. EmDash is a term associated with slop.
Well, an em dash is used in text to identify a pause or alternatives in the text.
..so like a fork in the way it's done, a new way of doing things.
But you need to remove the dev/ai hat in order to go back to writing rules and the real use.
Does Cloudflare use EmDash in production? Showing that its design and implementation have been refined through real-world use would help instil confidence.
Picking April First to launch is certainly a Decision.
Great job! I’ll move to this if it has:
- good caching - GUI in spanish - a cli like wp-cli
good cache control is essential for news sites with 100k + posts
Why would you gut the credibility of the project for that tagline then: why not skip mentioning agents?
You even open the article by linking the toy project where you used agents to "recreate Next in a week" and released with critical vulnerabilities.
What does "While EmDash aims to be compatible with WordPress functionality" mean?
Compatible how?
will all my custom Wordpress themes and plugins run on EmDash?
For plugins, no.
1- EmDash plugins are written in TypeScript, not PHP
2- EmDash plugins have a specific permissions model, where they need to explicitly request access to certain things.
3- WordPress plugins just invoke things. EmDash plugins have a defined API you use to talk to different capabilitites
4- Those capabilities are totally different, and at a different abstraction, than what WordPress provides.
Beyond the look of the admin interface and publishing flow, I don't see how this is a "Spirtual Successor" to WordPress at all. Its a CMS, designed from scratch, for a serverless world, using CF proprietary capabilities (D1 Databases, R2 for image/media storage, their workers for running things).
I agree with you, if you're already a competent engineer, your productivity only is improved by orders of magnitude by using coding agents that are at this point producing very good code as long as you give it the right prompts and you test your code and remove any bugs... if the code tests and all the bugs are removed, what you've got is a working product that is hard to argue that it doesn't work especially if there's been a lot of QA done on it and there's no bugs....
This doesn't really address the concern.
The question isn't whether this took longer than a weekend or whether you personally have open source experience, it's whether Emdash is actually being built as an open ecosystem or as a Cloudflare-bound platform. Bringing up your background reads like using prior credibility to justify the project's quality, instead of demonstrating it.
If it only runs properly on Cloudflare's infrastructure, then invoking "understanding open source and community" feels misleading. Those values usually imply portability and independent ecosystem growth, not tight platform coupling.
Also, "not vibeslop" here isn't about effort, it's about whether there's a clear, defensible reason this exists beyond being an AI-accelerated WordPress-like system tied to one vendor.
[flagged]
"Don't be snarky."
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
https://news.ycombinator.com/newsguidelines.html
There's a big difference between the two. If you still think agent-guided development doesnt work well, you need to update your priors
The slow enshittification of every product touched by LLMs these last few years (ESPECIALLY by Microsoft, who goes all-in) kind of “disproves” your point.
Reliable agent-coded development only seems to work for small codebases. (And it’s amazing in Ruby for some reasons.)
Agent coded != vibe coded.
I don't write code manually anymore, but Im still getting the exact code output that I want.
It's a tough pill for some HNers to swallow, but with a good process, you can vibe-code really good software, and software far more tested, edge-cased, and thoughtful than you would have come up with, especially for software that isn't that one hobby passion project that you love thinking about.
vibe coding implies a complete lack of process. The definition is basically YOLO....
https://x.com/karpathy/status/1886192184808149383
My process is just getting claude code to generate a plan file and then rinsing it through codex until it has no more advice left.
I'd consider it vibe-coding if you never read the code/plan.
For example, you could package this up in a bash alias `vibecode "my prompt"` instead of `claude -p "my prompt"` and it surely is still vibe-coding so long as you remain arms length from the plan/code itself.
I mean to be fair, if you are using agents more than likely you are not thinking about aspects of the code as deeply as you would have before. If you write things yourself you spend far more time thinking about every little decision that you're making.
Even for tests, I always thought the real valuable part of it was that it forced you to think about all the different cases, and that just having bunch of green checkboxes if anything was luring developers into a false sense of security
There's definitely a trade-off, but it's a lopsided one that favors AI.
Before AI, you were often encumbered with the superficial aspects of a plan or implementation. So much that we often would start implementing first and then kinda feel it out as we go, saving advanced considerations and edge-cases for the future since we're not even sure what the impl will be.
That's useful for getting a visceral read on how a solution might feel in its fetal stage. But it takes a lot of time/energy/commitment to look into the future to think about edge cases, tests, potential requirement churn, alternative options, etc. and planning today around that.
With AI, agents are really good at running preformed ideas to their conclusion and then fortify it with edge-cases, tests, and trade-offs. Now your expertise is better spent deciding among trade-offs and deciding on what the surface area looks like.
Something that also just came to mind is that before AI, you would get married to a solution/abstraction because it would be too expensive to rewrite code/tests. But now, refactoring and updating tests is trivial. You aren't committed to a bad solution anymore. Or, your tests are kinda lame and brittle because they're vibe-coded (as opposed to not existing at all)? Ok, AI will change them for you.
I also think we accidentally put our foot on the scale in these comparisons. The pre-AI developer we'll imagine as a unicorn who always spends time getting into the weeds to suss out the ideal solution of every ticket with infinite time and energy and enthusiasm. The post-AI developer we'll imagine as someone who is incompetent. And we'll pit them against each other to say "See? There's a regression".
I think I agree. Fast iteration in many cases > long thought out ideas going the wrong direction. The issue is purely a mentality one where AI makes it really easy to push features fast without spending as much time thinking through them.
That said, iteration is much more difficult on established codebases, especially with production workflows where you need to be more than extra careful your migration is backwards compatible, doesn't mess up feature x,y,z,d across 5 different projects relying on some field or logical property.
Unless you go through the code with a tooth comb, you're not even aware of what trade-offs the AI has made for you.
We've all just seen the Claude Code source code. 4k class files. Weird try/catches. Weird trade-offs. Basic bugs people have been begging to fix left untouched.
Yes, there's a revolution happening. Yes, it makes you more productive.
But stop huffing the kool-aid and be realistic. If you think you're still deciding about the trade-offs, I can tell you with sincerity that you should go try and refactor some of the code you're producing and see what trade-offs the AI is ACTUALLY making.
Until you actually work with the code again, it's ridiculously easy to miss the trade-offs the AI is making while it's churning out it's code.
I know this because we've got some AI heavy users on our team who often just throwing the AI code straight into the repo with properly checking it. And worse, on a code review, it looks right, but then when something goes wrong, you go "why did they make that decision?". And then you notice there's a very AI looking comment next to the code. And it clicks.
They didn't make that decision, they didn't choose between the trade-offs, the AI did.
I've seen weird timezone decisions, sorting, insane error catching theatre, changing parts of the code it shouldn't have even looked at, let alone changed. In the FE sphere it's got no clue how to use UseEffect or UseMemoization, it litters every div with tons of unnecessary CSS, it can't split up code for shit, in the backend world it's insanely bad at following prior art on things like what's the primary key field, what's the usual sorting priority, how it's supposed to use existing user contexts, etc.
And the amount of times it uses archaic code, from versions of the language 5-10 years ago is really frustrating. At least with Typescript + C#. With C# if you see anything that doesn't use the simpler namespacing or doesn't use primary constructors it's a dead give-away that it was written with AI.
I feel this is the key - three years ago everyone on HN would be able to define "technical debt" and how it was bad and they hated it but had to live with it.
We've now build a machine capable of something that can't even be called "technical debt" anymore - perhaps "technical usury" or something, and we're all supposed to love it.
Most coders know that support and maintenance of code will far outlast and out weigh the effort required to build it.
Shhhhh stop telling them! We don’t need more competition :)
This, but I think everybody that's awake knows this. I still not a fan of this project regardless, it's polishing a turd.
Produce this "far more tested, edge-cased, and thoughtful" vibe-coded software for us to judge, please.
All I hear are empty promises of better software, and in the same breath the declaration that quality is overrated and time-to-ship is why vibecoding will eventually win. It's either one, or the other.
I’ve said it before here, but my mind was swayed after talking with a product manager about AI coding. He offhandedly commented that “he’s been vibe coding for years, just with people”. He wasn’t thinking much about it at the time, but it resonated with me.
To some agents are tools. To others they are employees.
I had a similar realisation in IT support - I regularly discover the answers I get from junior-to mid-level engineers need to be verified, are based on false assumption or are wildly wrong, so why am I being so critical of LLM responses. Hopefully some day they’ll make it to senior engineer levels of reasoning, but in the meantime they’re just as good as many on the teams I work with and so have their place.
its the same thing. no one can keep up with their plan mode/spec driven whatever process. All agent driven projects become vibe coded "this is not working" projects.
Lot of ppl are only in the beginning stages so they think its different because they came up with some fancy looking formal process to generate vibe.
how long should it take to gain your confidence? how did you arrive at your number?
the state of the art of software engineering is to use AI. it's just reality
how long? 10 years
What are some other candidates in the "most meaningless new term" awards category? "Vibe coding" seems like the best in a generation. Even with a lot of clarifying qualifications, it often still seems fundamentally meaningless / open to interpretation / triggers commenters based on their priors.
Using the word priors in the way you (and others) do.
I started calling it LLM assisted coding. If you know what you’re doing but use LLMs to do tedious stuff and educate yourself on the unfamiliar bits you can move quite fast. The term vibe coding does not do that process justice imho.
> The term vibe coding does not do that process justice imho.
Well that's because actual vibe coding is a completely separate thing from "LLM assisted coding, know what you’re doing but use LLMs to do tedious stuff".
I'm not entirely sure what you mean by "started calling it", but vibe coding doesn't need a new name, it needs people to be clear about what they mean.
I think the jury is still out on this one, meaning people have different meanings when using the term "vibe coding".
OP says "vibe-coded months long project", imho that is not vibe coding? I'd say it's vibe coding if op does not know the programming language and just let the LLM write everything. This does not sound like it.
Vybrid coding :)
Well, it's a spectrum indeed, as everything is. As soon as we drawn lines the discussion start on where to draw them exactly. So it's, left to right:
One shotting --- vibe coding --- vybrid coding --- stack overflow assisted programming --- programming
Do we need any extra dimensions perhaps?
;)
Exactly. It might be fine. It might even be great!
But no matter how much code, including tests that AI can generate there was only one human thinking about those prompts, for a few months.
Any defects in that single human's thought process for overall architecture, security architecture, test architecture and coverage were not reviewed by any other human who might think differently and catch things that were missed. Ideally they were all at least reviewed by AI, but how differently operate from itself? It isn't particularly good at detecting its own errors without a human telling it to, which means the human needs to detect it in the first place.
Perhaps my most important point here is simply everyone here on HN is aware of all of these things, and as excited as some of us are about AI coded endeavors, the top response here will likely be the top response for many years - how do I know it isn't garbage? AI might be able to generate code fast, but informed users will definitely develop trust in it on a more human time scale.
I think the core idea of addressing a core architecture security defect in Wordpress has a legs. I'd make the case that the security architecture demonstrated here is table stakes for new software projects in 2026 when it clearly wasn't really conceivable in 2003. Though I'd also argue that many of the top Wordpress plugins should be shipped as "batteries included" in any successor, spiritual or otherwise - it would remain important to be extensible beyond those, securely.
A spiritual successor to Wordpress designed to run modern cloud infrastructure is a neat thing no doubt.
But after handling a bunch of horrible Wordpress and PHP stuff in my life lately, I'm tacking a bit of begging onto my hopefully useful response. Someone, anyone, AI coded or not, please work on a COMPLETE successor to Wordpress. And PHP really - though I do think taking care of Wordpress would entirely deal with the PHP problem.
What do I mean? All the modern table stakes stuff: * API first * fast bits in Rust (or Zig whatever IDK) * WASM * modern security architecture * batteries included - it is extremely dumb to have to add a plugin for calendars/dates/events and have about 100+ options for those. * designed to be deployed into modern clouds.. but also self-hostable on a single server, or colocated by small (cheap!) providers - ie: addressing ALL of the user base of Wordpress * one-click migration from Wordpress. Wordpress does this "with itself" to allow admins to move from one provider to another. Without this feature, might as well not bother
There is a business opportunity here I believe, though I'm not proposing a business model per se. A lot of people, myself included pay for Wordpress hosting while also hating it and being ready to leap at an alternative - even if it cost more.
This crap thinking has to stop, not everything is "hey agent do this" then sit, wait and publish as is. Also this is a Cloudflare official software, do you REALLY think this is 100% vibe coded without human intervention? Come on...
While I agree with your first sentence, I haven't been impressed with cloudflare's AI track record. I think my expectations for "cloudflare software on the HN front page that was significantly AI coded" are lower than "random guy's software on the HN front page that was significantly AI coded".
After https://news.ycombinator.com/item?id=46781516 ? Yes, one can unfortunately put that into the realm of reality.
Considering Cloudflare shat out slop in the form of a "complete rewrite of NextJS in one weekend" and proudly put out a blog post (https://blog.cloudflare.com/vinext/) despite how absolutely dogshit it is:
yeah.
If you read the first few sentences...
> But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
They have honed their AI OSS troll marketing chop and every step goes far and far. I'll take it more seriously once they start open sourcing vibe coded projects they actually use in their production.
I think Cloudflare has picked up that code velocity is only good if you can recruit users to a new open project, and have solid maintainers to keep the project going long term. Just from passive observance it feel like Cloudflare’s engineering team is chockful of seasoned maintainers. They then have a great social following already. So, code velocity, plus audience, plus maintainers, means you maybe can capture a lot of open projects under your umbrella while people are still trying to figure out how to fiddle with legacy software and AI. Meanwhile, “new is always better” puts pressure on legacy user bases. Finally, you allow these things to hook into your magnanimous global app development platform, and boom you have got it made in the shade.
This is such a valid concern. At this point I wouldn’t adopt new features unless they’ve been actively maintained and stable for 6 months. Too risky.
It’s definitely slop of some kind.
Why mixed ”permission:scope” and ”scope:permission”?It is 100% vibe coded.
I'm getting so exhausted of the "slop" accusation on new project launches. There are legit criticisms of EmDash in the parent comment that are overshadowed by the implication it was AI coded and, thus, unusable quality.
The problem is there's no beating the slop allegation. There's no "proof of work" that can be demonstrated in this comment section that satisfies, which you can see if you just keep following the entire chain. I'd rather read slop comments than this.
The main engineer of this project is in the comments and all he's being engaged with on is the definition of vibes.
They called the project EmDash and launched it on April 1st with a blog which brags about how little effort it took to write because of agents before even saying what it is.
If the product launch involves dressing the engineering team up in duck suits and releasing to a soundtrack of quacking, it's really not surprising people are asking the guy they hid behind the Daffy mask on why he's dressed as a duck rather than what he learned about headless CMS architecture from being on the Astro core team...
I know that it's discourteous to write-off a potentially valuable project because the release post showed a lack of self-awareness, but I think it's indicative of the larger struggle taking place: that trust is decaying.
It's decaying for a lot of the reasons displayed in the post, like you described, but the post also:
So yeah, maybe EmDash is revolutionary with respect to Wordpress, but it hasn't signaled trust, and that's a difficult hurdle to get past.This is a great point. I wish we started from this.
There's plenty of other comments saying this. It isn't that I don't understand, and need a clever metaphor.
But to run with your metaphor, can we, maybe, just ignore the quacking since we all know that's just how you get attention these days and instead focus on that other stuff? Because it seems like asking about the duck mask will never produce a satisfactory answer and instead turn into a debate on the merits of ducks.
Dare I suggest that this debate has become boring and beside the point. Unless someone on HN has been living under a rock they've already made up their mind about ducks.
Obtuse and repetitive debates is what HN comments are for. :)
But in this case it feels less like somebody has launched a revolutionary new product and HN is debating the MIT licence and landing page weight, and more like somebody has announced they've a plug-in replacement for a popular repository with a troll post and HN chooses not to spend enough time on Github to discover the all-star team and excellent architectural decisions the blog didn't bother mentioning.
Plus Cloudflare deliberately signalling that at best they're not very invested in its success and it might well just be low-effort slop probably is more pertinent to whether a purported WordPress replacement actually gains any traction than its technical merit, and headless CMS with vendor lockin vs managing WordPress security isn't likely to be a more productive debate than one on "slop". The target audience for this product is much more 'HN crowd' than 'read about agentic solutions to workforce automation on Gartner crowd' too, so the quacking alienating HN is actually relevant.
I mean the name is a nod to that.
Coded with AI != slop. AI in the hands of the right person can actually be good. That's gotten _especially_ true in the past few months.
Maybe what the parent commenter was referring to is that recently CloudFlare have published multiple vibe-code demo blog posts whilst trying to pass it off as production grade, for example https://news.ycombinator.com/item?id=46781516 where they implemented an open standard communication protocol on CloudFlare Workers.
The blog post was chock full of factual errors, claimed to be based off project X but wasn't at all and even had the cheek to include that it was arguably the most secure way to deploy such a server, with their implementation apparently already being used by their team to serve real traffic. Meanwhile the repo was full of TODOs for all the security aspects of the protocol.
Of course after the backlash a lot of this was covered up so look at the archives if you are curious.
They have really done a disservice to themselves because their blog posts used to be excellent, but now I have to question whether it's another blogpost full of fakery like that one (and there was another since iirc). Given this blog post talks about reimplementing a popular project, it starts to give off the signs of being another one of these. Unfortunate if that's not the case
CloudFlare announcements have caused them to lose credibility in this area.
IMO, what matters is whether it's coded with AI or it's coded by AI.
Is AI merely being used as a tool to aid the engineer? Because that's what I do. I use it as essentially a super-autocomplete. It typically only writes a couple lines at a time for me. On rare occasions, I can write a function signature and let it fill out the body. That's coding with AI.
Anything more than that though? You're stepping into coding by AI, which utterly fails at anything beyond an MVP. Once you go over 2,000 lines of code or so, it falls apart. It can't reason about anything with even a small amount of complexity, and every "bug fix" either fails to fix the bug or it introduces two more.
whether people want to admit it or not, agent encoding is kind of the norm right now and I think the fear is the stories coming out of places like Block, Inc where they announced they fired 4,000 engineers a couple days ago because of what's the obvious truth today versus 6 months ago.... one expert software engineer can do the work of 20-40 people, so why do we need so many people? it's a hard pill to swallow, it's easier to claim that agentic coding doesn't work or that the code is sloppy and it doesn't work when in reality most companies are currently using it everyday, especially the large ones.
EmDash is a stupid name
plug-in security
I am not sure if this is an April fool joke anymore in the age of AI.
The problem is that it doesn't solve the network-effect problem.
People aren't on WordPress because of WordPress.
They're on WordPress because of WooCommerce, a million themes, BuddyPress, integrations for every stupid internal business API on the planet (many of which are terrible and were written by an idiot with a crayon).
The APIs will have no testing because they are bad. In many cases the WordPress implementation of the API written in the codeblock, ran on page-load to the pain of the person responsible for SEO, is the API contract.
And yes those plugins are also terrible, but they solve business problems, even if they are tech problems.
You can't just launch a better wp-core and expect it to replace any of that.
EmDash needs to actually run the existing insecure WP plugins to takeover.
You seem to have missed the point. This is intended to be more secure in a new world where exploits will be cheap to discover. The factors you mention won't keep people onboard if systems are compromised every day in too many ways for fragmented security teams to keep on top of.
Name it CloudPress
Tangential rant about WP.
Having got back in to some WP in the last year, the big thing that struck me compared to other framework/environments is... no... build step, or even plugin/module install step. Files are just there in the document root, accessible by default - the logic files are invokable and the asset files are reachable. Most other php frameworks will install a plugin/module outside the document root then have some sort of publish/install step that will copy assets to be publicly accessible as needed. No plugin logic files would be invokable directly from a URL. That one change would make a big difference, imo, but seeing so much of the last 15-20 years of WP involves helper functions to assumed paths, and default assumptions about assets and logic living in the same paths... I'm not sure the ecosystem could adapt or support an alternative approach at this stage. Might be wrong. It's taken me a while to put my finger on why the current situation encourages less-secure-by-default systems, and this is probably the biggest thing I've landed on. There are other issues, but these issues all help contribute to WP popularity in the first place...
The lede everyone is burying: "Every EmDash site has x402 support built in — charge for access to content"
Here to say -- great name. It's not just a reference to our modern times, it's a sign of brilliance. (I wrote this myself with no clanker support)
Wordpress is PHP, which has developer base insanely larger then typescript. Also, a lot cheaper. Compete with that.
Your first statement is wildly and verifiably untrue (see: https://survey.stackoverflow.co/2025/technology#most-popular...) and your second statement doesn't make sense. I've got like 8 sites on Pages/Workers with R1 + vectorize databases scattered around and I'm not paying a dime for any of that. What cost are you talking about?
Coding agents make this much less important.
You want a spiritual successor? We have Ghost.
You want anything beyond ghost? Find a way to port the vast market of 100,000+ cheap and free themes and components that are available to enable tech-illiterate, low-budget users to basically build an entire business platform on a $5/mo shared hosting plan.
A vibe coded CMS that's 3 months in the making is not capable of taking that place in the market, no matter how much VC funding you put behind it.
I think wordpress, woo commerce and elementor are in a Mexican standoff. Wordpress cant fork or change in a major way because the other two are so popular no one would use the new variant. woo commercere and elementor can't just walk away and make their own wordpress-less platform because they rely on each other and the other constellation of plugins that run on wordpress.
WooCommerce is owned by the same company as Wordpress. Elementor is just one page builder of many in the vast ecosystem you mention, but much of that ecosystem can be ported. As replacing the core CMS goes, Emdash might be able to conquer, but time will tell as to whether it's able to rule.
It’s written in typescript, not PHP. How does this improve security if no one uses it because they’ve invested so much in the WP plugin ecosystem?
This looks nice.
Can a successor for Wordpres shave some amount or type of import, conversion, or backwards compatibility?
Can there. ba way to tie in wordpress plugins or their functionality through a secure interface/translation layer?
Adoption for new projects is one thing, migration is another.
There's some cms that pretty much build in some core amount of main plugins right into the core cms.
I for one am glad that WordPress has some competition. This sounds like a killer rewrite.
This reminds me of Linus Torvalds about Git, criticizing that SVN did present itself as "CVS done right" for... "It's impossible to get CVS right". Which I found incredibly funny and witty.
Is the second coming of Wordpress what we really need?
Spiritually bankrupt, that should just be considered marketing material.
Payload
Will be there a way to export all the posts to markdown so you never get locked in?
Damm Anthropic had a chance to say april fools too for the claude code leak!!
EmDash on Apr 1 come on guys
"Failed to initialize playground"
Try again once or twice.
Impressive and created by agents. Another example for skeptics wondering where the AI apps are.
I think this is too soon to call. No one questions whether AI can build things. We question whether they can build stable things that work as expected and stay online in the long run.
I too have seen a lot of comments asking where the products are. If you're now moving the goal posts to "stay online in the long run" you're gonna have to wait until there's been a long run to stay online in. Agents aren't that old yet.
The stability question is real but I think it's framed wrong. The issue isn't whether an agent can write correct code in a single session -- they can, and pretty reliably now. It's whether there's a human with enough understanding of the codebase to debug it when something breaks at 2am.
I run parallel coding agents on my own projects daily. The code they produce is fine. What worries me is the "just ship it" energy where nobody on the team deeply understands what got built. That's not an AI problem, it's been a problem with outsourced codebases forever. AI just makes it faster to accumulate code nobody fully groks.
Cloudflare probably has the engineering depth to maintain this regardless of how it was built. A lot of other teams don't.
This will largely be based on the maintainers’ priorities. Coding agents can audit and clean up code too, provided that you set the right goals.
> "Failed to initialize playground"
Impressive indeed!
Try again a few times, it ends up loading.
The successor to WordPress will wear out the F5 key
did you test it? How do you know it works?
if this can implode the crooked "web hosting industry" that surrounds the lamp / wordpress ecosystem the better.
Ha! Nice April Fools joke. Nothing will succeed WordPress. Not even AGI. Specially not something with the name EmDash. Good one Cloudflare.
deployed it on vercel for lolz - it works!
Why?!
Half the websites on wordpress moved to shopify, squarespace, etc. a very long time ago. The remaining half were blogs, personal pages, wikis, etc. that moved to community/social platforms created in the past decade(s). In a few cases out of all this someone finally learned how to write/host a webpage themselves (imagine that)! It's even easier with AI now.
I'm totally serious when I ask "why". Who actually uses a CMS or anything like that anymore? It's madness!
After all the AI slop from Cloudflare in recent months and the embarrassment that came with it, they dare to launch this vibe coded project with THAT name on April 1st? I'm really not sure what to think anymore. Reality became too absurd.
Lol, build the same level of community first, then we’ll talk
Is this just literally turning plugins into microservices? Lol
Held up getting into the details of this ambitious project because of the name! Ridiculous choice considering the associations with AI, slop, and even the general crowded namespace surrounding that. C'mon.
(looks for cameras) Wait a minute, am I being Punk'D? Oh my god! Ashton, you really got me! Ha Ha! Ashton!
From the people who brought you "we used AI to undercut a project we use rather than pay them fairly for the work we relied on" comes an exciting new lawsuit by Mullenweg for using Wordpress in their product description.