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.

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.

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.

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.

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.

Most WordPress plugin vulnerabilities would not exist if Wordpress would expose only a public folder to the web without including `wp-content/plugins/`.

This would avoid plugin scanning and direct plugin code execution.

For the CMS I'm developing, Vvveb CMS, no plugin code is exposed, everything passes through the only exposed php file `public/index.php`

I like the where this is going. The plugins are always the biggest threat. The biggest hurdle will be adoption with all other platforms. One reason WP is still the most used is because all other services you'd ever want to integrate with offer some sort of plugin or integration with WP. Also, so many people use it you know there will always be someone to assist if needed.

I don't like where any of this is going

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.

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.