E: Oh, I think it's an April fools joke, I'm embarrassed.
E2: Apparently not a joke.
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.
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.
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.
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".
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 users use at least one plugin: it is the appeal of the product.
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."
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
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.
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.
Anything built on PHP will be widely used, like Laravel
Is this April fools? With real products launching on this date you can't really be too sure.
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.
yes you want a global db handle sure ya lets delete all tables woohoo
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.
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'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.
> no WordPress code was used to create EmDash
Hm. Do you think those agents were trained on WP code?
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.
Also, there are successful alternatives to Wordpress too, so the most likely outcome is that it becomes yet another alternative.
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".
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.
"Better coded" is very much a subjective assessment.
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.
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.
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.
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.
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.
It's not illegal to make product comparisons. That's just competition.
I guess this is our answer to the question of why Cloudflare acquired it in the first place.
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.
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.
A system for using Federated and Independent Repositories in WordPress
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.
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.
> 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.
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.
capabilities: ["read:content", "email:send"],
Why mixed ”permission:scope” and ”scope:permission”?> 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.
You just put the comments into something like firebase/supabase etc or use one of many off the shelf solutions. Free tier is fine.
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.
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.
They announced 1.1.1.1 on April 1st way back in 2018 too.
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.
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.
You could just do it with CGI scripts, without the external dependencies, but that isn't really static either.
2026-04-01
11 min read

The cost of building software has drastically decreased. We recently rebuilt Next.js in one week using AI coding agents. 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.
WordPress powers over 40% of the Internet. It is a massive success that has enabled anyone to be a publisher, and created a global community of WordPress developers. But the WordPress open source project will be 24 years old this year. Hosting a website has changed dramatically during that time. When WordPress was born, AWS EC2 didn’t exist. In the intervening years, that task has gone from renting virtual private servers, to uploading a JavaScript bundle to a globally distributed network at virtually no cost. It’s time to upgrade the most popular CMS on the Internet to take advantage of this change.
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.
EmDash is fully open source, MIT licensed, and available on GitHub. 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. We hope that allows more developers to adapt, extend, and participate in EmDash’s development.
You can deploy the EmDash v0.1.0 preview to your own Cloudflare account, or to any Node.js server today as part of our early developer beta:
Or you can try out the admin interface here in the EmDash Playground:

The story of WordPress is a triumph of open source that enabled publishing at a scale never before seen. Few projects have had the same recognisable impact on the generation raised on the Internet. The contributors to WordPress’s core, and its many thousands of plugin and theme developers have built a platform that democratised publishing for millions; many lives and livelihoods being transformed by this ubiquitous software.
There will always be a place for WordPress, but there is also a lot more space for the world of content publishing to grow. A decade ago, people picking up a keyboard universally learned to publish their blogs with WordPress. Today it’s just as likely that person picks up Astro, or another TypeScript framework to learn and build with. The ecosystem needs an option that empowers a wide audience, in the same way it needed WordPress 23 years ago.
EmDash is committed to building on what WordPress created: an open source publishing stack that anyone can install and use at little cost, while fixing the core problems that WordPress cannot solve.
WordPress’ plugin architecture is fundamentally insecure. 96% of security issues for WordPress sites originate in plugins. In 2025, more high severity vulnerabilities were found in the WordPress ecosystem than the previous two years combined.
Why, after over two decades, is WordPress plugin security so problematic?
A WordPress plugin is a PHP script that hooks directly into WordPress to add or modify functionality. There is no isolation: a WordPress plugin has direct access to the WordPress site’s database and filesystem. When you install a WordPress plugin, you are trusting it with access to nearly everything, and trusting it to handle every malicious input or edge case perfectly.
EmDash solves this. In EmDash, each plugin runs in its own isolated sandbox: a Dynamic Worker. Rather than giving direct access to underlying data, EmDash provides the plugin with capabilities via bindings, based on what the plugin explicitly declares that it needs in its manifest. This security model has a strict guarantee: an EmDash plugin can only perform the actions explicitly declared in its manifest. You can know and trust upfront, before installing a plugin, exactly what you are granting it permission to do, similar to going through an OAuth flow and granting a 3rd party app a specific set of scoped permissions.

For example, a plugin that sends an email after a content item gets saved looks like this:
import { definePlugin } from "emdash";
export default () =>
definePlugin({
id: "notify-on-publish",
version: "1.0.0",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "posts" || event.content.status !== "published") return;
await ctx.email!.send({
to: "[email protected]",
subject: `New post published: ${event.content.title}`,
text: `"${event.content.title}" is now live.`,
});
ctx.log.info(`Notified editors about ${event.content.id}`);
},
},
});
This plugin explicitly requests two capabilities: content:afterSave to hook into the content lifecycle, and email:send to access the ctx.email function. It is impossible for the plugin to do anything other than use these capabilities. It has no external network access. If it does need network access, it can specify the exact hostname it needs to talk to, as part of its definition, and be granted only the ability to communicate with a particular hostname.
And in all cases, because the plugin’s needs are declared statically, upfront, it can always be clear exactly what the plugin is asking for permission to be able to do, at install time. A platform or administrator could define rules for what plugins are or aren’t allowed to be installed by certain groups of users, based on what permissions they request, rather than an allowlist of approved or safe plugins.
WordPress plugin security is such a real risk that Wordpress.com manually reviews and approves each plugin in its marketplace. At the time of writing, that review queue is over 800 plugins long, and takes at least two weeks to traverse. The vulnerability surface area of WordPress plugins is so wide that in practice, all parties rely on marketplace reputation, ratings and reviews. And because WordPress plugins run in the same execution context as WordPress itself and are so deeply intertwined with WordPress code, some argue they must carry forward WordPress’ GPL license.
These realities combine to create a chilling effect on developers building plugins, and on platforms hosting WordPress sites.
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.
EmDash plugins have two important properties that mitigate this marketplace lock-in:
Plugins can have any license: they run independently of EmDash and share no code. It’s the plugin author’s choice.
Plugin code runs independently in a secure sandbox: a plugin can be provided to an EmDash site, and trusted, without the EmDash site ever seeing the code.
The first part is straightforward — as the plugin author, you choose what license you want. The same way you can when publishing to NPM, PyPi, Packagist or any other registry. It’s an open ecosystem for all, and up to the community, not the EmDash project, what license you use for plugins and themes.
The second part is where EmDash’s plugin architecture breaks free of the centralized marketplace.
Developers need to rely on a third party marketplace having vetted the plugin far less to be able to make decisions about whether to use or trust it. Consider the example plugin above that sends emails after content is saved; the plugin declares three things:
It only runs on the content:afterSave hook
It has the read:content capability
It has the email:send capability
The plugin can have tens of thousands of lines of code in it, but unlike a WordPress plugin that has access to everything and can talk to the public Internet, the person adding the plugin knows exactly what access they are granting to it. The clearly defined boundaries allow you to make informed decisions about security risks and to zoom in on more specific risks that relate directly to the capabilities the plugin is given.
The more that both sites and platforms can trust the security model to provide constraints, the more that sites and platforms can trust plugins, and break free of centralized control of marketplaces and reputation. Put another way: if you trust that food safety is enforced in your city, you’ll be adventurous and try new places. If you can’t trust that there might be a staple in your soup, you’ll be consulting Google before every new place you try, and it’s harder for everyone to open new restaurants.
The business model of the web is at risk, particularly for content creators and publishers. The old way of making content widely accessible, allowing all clients free access in exchange for traffic, breaks when there is no human looking at a site to advertise to, and the client is instead their agent accessing the web on their behalf. Creators need ways to continue to make money in this new world of agents, and to build new kinds of websites that serve what people’s agents need and will pay for. Decades ago a new wave of creators created websites that became great businesses (often using WordPress to power them) and a similar opportunity exists today.
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.
EmDash has built-in support for x402. This means anyone with an EmDash site can charge for access to their content without requiring subscriptions and with zero engineering work. All you need to do is configure which content should require payment, set how much to charge, and provide a Wallet address. The request/response flow ends up looking like this:

Every EmDash site has a built-in business model for the AI era.
WordPress is not serverless: it requires provisioning and managing servers, scaling them up and down like a traditional web application. To maximize performance, and to be able to handle traffic spikes, there’s no avoiding the need to pre-provision instances and run some amount of idle compute, or share resources in ways that limit performance. This is particularly true for sites with content that must be server rendered and cannot be cached.
EmDash is different: it’s built to run on serverless platforms, and make the most out of the v8 isolate architecture of Cloudflare’s open source runtime workerd. On an incoming request, the Workers runtime instantly spins up an isolate to execute code and serve a response. It scales back down to zero if there are no requests. And it only bills for CPU time (time spent doing actual work).

You can run EmDash anywhere, on any Node.js server — but on Cloudflare you can run millions of instances of EmDash using Cloudflare for Platforms that each instantly scale fully to zero or up to as many RPS as you need to handle, using the exact same network and runtime that the biggest websites in the world rely on.
Beyond cost optimizations and performance benefits, we’ve bet on this architecture at Cloudflare in part because we believe in having low cost and free tiers, and that everyone should be able to build websites that scale. We’re excited to help platforms extend the benefits of this architecture to their own customers, both big and small.
EmDash is powered by Astro, the web framework for content-driven websites. To create an EmDash theme, you create an Astro project that includes:
Pages: Astro routes for rendering content (homepage, blog posts, archives, etc.)
Layouts: Shared HTML structure
Components: Reusable UI elements (navigation, cards, footers)
Styles: CSS or Tailwind configuration
A seed file: JSON that tells the CMS what content types and fields to create
This makes creating themes familiar to frontend developers who are increasingly choosing Astro, and to LLMs which are already trained on Astro.
WordPress themes, though incredibly flexible, operate with a lot of the same security risks as plugins, and the more popular and commonplace your theme, the more of a target it is. Themes run through integrating with functions.php which is an all-encompassing execution environment, enabling your theme to be both incredibly powerful and potentially dangerous. EmDash themes, as with dynamic plugins, turns this expectation on its head. Your theme can never perform database operations.
The least fun part about working with any CMS is doing the rote migration of content: finding and replacing strings, migrating custom fields from one format to another, renaming, reordering and moving things around. This is either boring repetitive work or requires one-off scripts and “single-use” plugins and tools that are usually neither fun to write nor to use.
EmDash is designed to be managed programmatically by your AI agents. It provides the context and the tools that your agents need, including:
Agent Skills: Each EmDash instance includes Agent Skills that describe to your agent the capabilities EmDash can provide to plugins, the hooks that can trigger plugins, guidance on how to structure a plugin, and even how to port legacy WordPress themes to EmDash natively. When you give an agent an EmDash codebase, EmDash provides everything the agent needs to be able to customize your site in the way you need.
EmDash CLI: The EmDash CLI enables your agent to interact programmatically with your local or remote instance of EmDash. You can upload media, search for content, create and manage schemas, and do the same set of things you can do in the Admin UI.
Built-in MCP Server: Every EmDash instance provides its own remote Model Context Protocol (MCP) server, allowing you to do the same set of things you can do in the Admin UI.
EmDash uses passkey-based authentication by default, meaning there are no passwords to leak and no brute-force vectors to defend against. User management includes familiar role-based access control out of the box: administrators, editors, authors, and contributors, each scoped strictly to the actions they need. Authentication is pluggable, so you can set EmDash up to work with your SSO provider, and automatically provision access based on IdP metadata.
You can import an existing WordPress site by either going to WordPress admin and exporting a WXR file, or by installing the EmDash Exporter plugin on a WordPress site, which configures a secure endpoint that is only exposed to you, and protected by a WordPress Application Password you control. Migrating content takes just a few minutes, and automatically works to bring any attached media into EmDash’s media library.

Creating any custom content types on WordPress that are not a Post or a Page has meant installing heavy plugins like Advanced Custom Fields, and squeezing the result into a crowded WordPress posts table. EmDash does things differently: you can define a schema directly in the admin panel, which will create entirely new EmDash collections for you, separately ordered in the database. On import, you can use the same capabilities to take any custom post types from WordPress, and create an EmDash content type from it.
For bespoke blocks, you can use the EmDash Block Kit Agent Skill to instruct your agent of choice and build them for EmDash.

EmDash is v0.1.0 preview, and we’d love you to try it, give feedback, and we welcome contributions to the EmDash GitHub repository.
If you’re just playing around and want to first understand what’s possible — try out the admin interface in the EmDash Playground.
To create a new EmDash site locally, via the CLI, run:
npm create emdash@latest
Or you can do the same via the Cloudflare dashboard below:
We’re excited to see what you build, and if you're active in the WordPress community, as a hosting platform, a plugin or theme author, or otherwise — we’d love to hear from you. Email us at [email protected], and tell us what you’d like to see from the EmDash project.
If you want to stay up to date with major EmDash developments, you can leave your email address here.
Cloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale applications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at bay, and can help you on your journey to Zero Trust.
Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.
To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Performance says they’re definitely still static sites!
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.
- good caching - GUI in spanish - a cli like wp-cli
good cache control is essential for news sites with 100k + posts
That was worth a disclosure in the post. Knowing this now and then going back to Ctrl+F on "Astro" gives a definite feel on the second reading that wasn't obvious the first time around.
That's the significant part of Wordpress after all, not the mediocre code.
Compatible how?
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).
¹https://developers.cloudflare.com/directory/?product-group=D...
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.
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.
..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.
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
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