Posted by elithrar 1 day ago
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 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.
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!
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 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.
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
p.s. still no contact form :)
“ And under the hood, EmDash is powered by Astro, the fastest web framework for content-driven websites.”
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.
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.
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."
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.
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
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
Can you explain why TS is spot on?
- 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.
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.
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.
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.
But there are many many "WordPress" developers out there that only know how to glue plugins together, so you often end up with plugin soup.
In the hands of someone who actually knows how to code you don't have any issues.
> 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.
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 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.
I’m very happy with WP, but I’ll be cheering on EmDash if it gets momentum.
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.
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!
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. :)
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.
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.
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.
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.
Yeah just invalidate the SSR cluster for your tiny footer update and let it prewarm until coffee break. Easy.
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.
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.
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.
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.
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
and you could call it "EmDash"
I suppose this is the world we live in.
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.
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.
> 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!
E: Oh, I think it's an April fools joke, I'm embarrassed.
E2: Apparently not a joke.
could just be a coincidence
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".
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.
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.
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.
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.
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.
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.
"Better coded" is very much a subjective assessment.
I really appreciate your work and even more that you took time and risk exposing your findings, I wish more people did this.
yes you want a global db handle sure ya lets delete all tables woohoo
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.
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'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.
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.
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).
That has been my experience, low barrier to entry, low price, shoddy work. Or hire an agency, pay top dollar for little work.
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.
If I was doing it in a recurring basis I would investigate creating a process to export the menu data and import directly using a custom plugin. Or create (via plugin) and endpoint to sync both environments (a bit more work).
I did this one time before for a subset of pages and admin users. There are likely plugins that do this already but you could likely roll your own just for menus in an hour imho.
Fast-forward to last year and I'm asked to look at it again. Surely, I think, in the ensuing time somebody would have rectified the architectural stupidity. It's a wildly popular platform, I thought. Surely it can't still be so terrible...
Fool me twice, I guess. >sigh<
This just sounds like deploying web software. You always have static assets that need to be deployed, the code/binary itself, and database migrations.
The insane part is the search-and-replace on the database backup to find hard-coded URLs referencing the environment's hostname. That's ridiculous. It speaks to the lack of serious operational experience that went into building the software.
I moved away from Wordpress altogether earlier this year because I got tired of babysitting MySQL.
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 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.