The thing that made WordPress win was not the editor. It was that you could download a theme and have a site that looked like something.

A theme is a bundle of templates plus assets, living inside the CMS, executed by the CMS, with access to everything the CMS knows. single.php renders a post. archive.php renders a list. The loop pulls the current query into scope and you write markup around it. It is enormously effective. It is also the tightest coupling in the entire system and almost nobody examines it, because it is simply how things have always been.

What the coupling buys is real. One install, one deploy, one thing to back up. The template has the whole content model available with no serialisation boundary, so you can ask for the author's other posts in the middle of rendering and it just works. A designer who knows PHP and nothing else can ship a complete site.

What it costs shows up later.

The rendering language is chosen for you. If the CMS is PHP, your frontend is PHP, and it stays PHP for the lifetime of the site regardless of what your team knows or what the site needs to become.

Performance is bound to the CMS. Every page view enters the application, hits the database and renders. The industry response was caching layers, then caching plugins to configure the caching layers, then a hosting industry built on getting the caching right for you.

And it makes the content unavailable to anything else. A mobile app, a newsletter, a second site, a screen in a lobby. All of them need the content and the only way in is scraping HTML or bolting on an API afterwards. WordPress added a REST API in 2015 and it still shows that it was added rather than designed in.

The alternative had been sitting there since the nineties, which is that a CMS produces content and something else produces pages. Vignette worked that way. It fell out of fashion because in 2005 running two things was harder than running one.

By around 2015 it stopped being harder. Static hosting became free, build pipelines became normal, and the argument for putting the renderer inside the CMS weakened considerably.

I want to be careful not to overclaim, because decoupling has a real bill attached. Two systems, two deploys, a build step between a change and a visible page, and previews that are suddenly a feature somebody has to implement rather than a thing that just happens. The coupled model is still the right answer for a great many sites, and the people who say otherwise are usually not the ones maintaining them.

But it is a decision, and for twenty years it was not treated as one. The next few of these are about what happened when people finally started treating it as one.