On Web Publishing and 'Simplicity'

Every time I see a new CMS or a trend in CMSs, 'simplicity' is touted as a selling point.

This is a thing because web publishing is inherently complicated and people want to reduce that complexity. Simplicity is also often used synonymously with "faster performance".

For example, a lot of people who promote systems like Jekyll and Kirby will say they are "simpler" compared to WordPress because they don't need a database engine to work.

It's my current belief that, given a particular computing environment and a particular data set, both complexity and performance are conserved in web publishing, no matter what workflow or tool-set is used.

That's to say, the complexity of any given step in the process of web publishing is reduced only by shifting that complexity to the other steps. Total complexity remains constant.

I'm borrowing scientific terms to convey my thought but doing so in a loose way, since I have no way to quantify "complexity" in this case. It's a subjective combination of how many steps are needed to get things done -- and how much effort and mental overhead is needed to accomplish them.

Web publishing steps:

1. Initial hosting setup (happens once per host)
2. Initial design (happens once)
3. Drafting content (regular)
4. Posting content (regular)
5. Editing content (regular)
6. Serving content (regular)
7. Backing up content from (not within) host (ideally regular)
8. Hosting maintenance (regular)
9. Changing design/presentation of content (infrequent)
10. Moving everything to a new host (infrequent)

Let's also get one other thing straight, regarding "caching".

This quote from How We Build CMS-Free Websites is representative of the misunderstanding I'm getting at:

CMSs consisted of templating logic, application code, and content databases so they could assemble webpages each time they were requested by site visitors. They were complicated systems that depend on many separate applications working together, like a web server to route page requests to a PHP application that uses pre-defined page layout templates to format content that’s stored in a MySQL database... In the end though, the ability to keep the website “up” and serving content at pace with a deluge of requests depends on the developers’ ability to turn on new servers and a reliance on caching schemes.

Let's be clear that -- even without a database -- unless you're authoring content as complete, raw HTML pages, you're using a caching scheme. The only difference at that point is the method used to invalidate and regenerate the cache.

At one extreme, we can see that Twitter and Facebook

• make web publishing completely simple for authors of no technical ability whatsoever -- but only at steps 3, 4 and 5;
• shift that difficulty to either side of the publishing lifecycle: steps 1-2, step 6 and step 8;
• make you dependent upon them for step 7 (backup) (Twitter makes this easy, Facebook makes it impossible);
• make steps 9 and 10 effectively impossible.

It's important to be clear about the 10 steps given above.

They represent sets of actions needed to accomplish each task and the complexity of those actions.

The complexity we care about is not simply that which the author perceives or experiences, but the total complexity of the entire system involved.