> 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.
I've managed a couple of WordPress installs for friends and family and my experience has largely been the opposite in that there's very little truly dynamic content. Of the dynamic content, the vast majority could just be an API (either home-grown or paid 3rd party SaaS).
The flip side of the dynamic content is that every Wordpress I've ever worked on is a horrifying mountain of plugins managed by the world's worst package manager. Plugin A needs to be updated because it has a vulnerability, which requires plugin B to be updated, but the theme hasn't gotten updates in 6 years and plugin B is using new stuff the theme doesn't support, so either the site has to be re-built with a new theme or plugin A just needs to be left at a vulnerable version.
Static sites get around some of that because vulnerable plugins only exist at build-time. I'm not worried about using an old version of Hugo or Jekyll, but I'm very worried about using old Wordpress plugins.
I've done so, so little work with Wordpress, but that experience was enough to convince me that I'd rather spend my days looking for dropped coins on the sidewalk than work with Wordpress again.
Is EmDash built with static sites as a focus? I haven't found too much about it yet, I was assuming it does (or will) focus on server rendering with cloudflare caching when possible.
Are you referring to static vs SSR, or caching? I'd expect static vs SSR to be an Astro concern rather than an EmDash concern. If they didn't integrate at all with Cloudflare for caching out of the box that seems like a miss, though I could see it needing to be a separate plugin if they want to expose all the configurability possible.
My wife's wordpress blog has at least 5 different plug-ins for publishing an article without a header. Every time I fix it for her by removing all but 1 plug-in, she'll install a million others because that's what ChatGPT told her to do.
I have no hope nor expectations of non-technical people performing technical tasks no matter how advanced AI becomes. The only solution is a platform/CMS that already has the all bells and whistles included.
a friend of mine owns a very popular psych/stoner label
until 3 days ago the website was a bunch of static pages, updated by the "webmaster", no shopping cart, no search, no contact form, just the email on the website
he and his employers have been living out of selling records and band merchandising for more than a decade, before he even created a real company
wanna buy a record?
press a button that sends you to the paypal cart
wanna pre order?
there is a preorder product on paypal, were you can put your shipping address and when it's ready, it'll be shipped to you
he's been selling in Europe and overseas in the US since the day he started
Now it got to the point where he needed to put different currencies for different regions, taxes, tariffs (UK, USA) so he built a new website that (automatically I guess) show the prices in the local currencies and stuff like that
I don't think they disagree? They said that okay, that doesn't perfectly fit into the static site philosophy but he can hack something together. Which is correct.
Your comment is basically agreeing with the parent comment. The free WYSIWYG version of WP was more accessible for laypersons to build their own site and add plugins as they went along. Developers noticed that and started building for WP over other platforms, betting that those layperson-made sites would eventually need features beyond a contact form (appointment scheduling, ecommerce storefronts, sandboxed customer account creation, etc.)
Ecosystem was a huge driver. But even before that, so so easy to get going. 5 minute guided install, if you're doing it yourself. Many web hosting providers auto-installed for you. No one could touch that ease to just get going.
I once did a review of CMSs to see "is there anything better out there?" Literally scores of options. At one point seemed like everyone had tried their hand at building a CMS. Installed maybe a dozen of the most promising. It was all very meh. Some had this nice feature or that (e.g. WYSIWYG editing, back when that wasn't table stacks). But overall, none seemed substantially better that WP, Drupal and Joomla among them. Most of them seemed blighted by comparison. Drupal and Joomla included. Nothing else out there seemed worthy of investing time and energy into.
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.
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.
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.
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.
Slightly late to this party, but in my opinion, this doesn't go nearly far enough. This solution will be relevant for 12 months in it's current form. If it adapts further, it might have legs.
I've built Wordpress sites for 12 years. Very few Wordpress developers are trying to swap to a slightly upgraded version of the same thing with no ecosystem and much of the same solutions. This will see some adoption, no doubt, but not a serious dent.
The main reason for that: in 12 months, 24 months, 36 months, this solution will be outdated and unimportant, same as Wordpress. Wordpress will still be kicking because it already has a 40% market share on the entire internet. This, however, will not be.
The CMS is dead tech in six to twelve months. I might have a million people who will disagree with me (and yes, people will still use CMS's after twelve months), but people actually moving into the future will have dropped CMS's for architectures that are AI first with strong, intuitive, easy-to-leverage guardrails.
In my opinion, the vast majority of people are still looking at AI through the lens of "how does it alter my current work/tech stack/strategy" and failing to ask the proper question: "what the hell is even important in a world where AI is as competent as 90% of humans and 100x faster?"
What do you need a CMS for? You think you'll be managing the content? Why? Why do I want a human managing content when the AI does it 100x as fast? Why do I want Astro? It compiles down nicely? Okay, maybe its a god-tier solution, but more likely... AI can just code extremely fast vanilla html/css/js. Why do I need a component library when AI can steal all the best components from all the best libraries? Why do I need "Portable Text"?
This is still not big picture enough. Think further out than 12 months.
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
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.
> 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.
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.
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.
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.