Home Static Sites vs. CMS
Post
Cancel

Static Sites vs. CMS

Static Sites vs. CMS

I just completed the migration and creation of three websites from tools like WordPress and Ghost, and the state of modern web tools remains extraordinarily broken. The root of the issue lies in the fact that the underpinnings of the web are fragile, not designed for dealing with files and folders. Beyond that, the core architecture of web page design is equally flawed.

Before I dive too deep, let’s agree on a few things:

  1. Users don’t care what tools or CMS were used to create a functional webpage; they care about the ultimate output.
  2. Users don’t care about JavaScript libraries, CSS, SCSS, cache files, webp, or other implementation details.
  3. Web designers want sites to work on all browsers with minimal compatibility issues, minimal dependency breakage, and maximum performance.

With those baselines out of the way, one has to wonder why the Web is still so broken. On the CMS side, tools like WordPress make direct interaction and editing an incredibly slow and arduous process. Themes and plugins add functionality but require constant editing and maintenance. These tools expose the ugly semantics of HTML and style sheets, leaving the end user constantly fighting with the tool. On the static site generation side, sites can be built with amazing performance. This site, which you’re likely reading, is entirely statically generated, and the search and interactions are blazing fast. However, they require a lot of technical expertise to get working. I wrote about some of these challenges with CSS over a decade ago and CSS and HTML have not improved.

The underpinnings of the web are more fragile, and the technical barrier to building a quality site is getting worse, not better. The recent advents of AI make me wonder if there are opportunities to rebuild larger portions of the web with very small teams. If performance and user experience are core to site performance, there is a massive opportunity to create a CMS that is lightning fast and has the UX to appeal to the masses without the walled garden of Squarespace, Wix, and similar sites.

Static site generators like Jekyll (powering this site), Hugo, and Gatsby provide more direct interaction on files but they operate at a very low level. These sites are tuned to markdown and manually uploading files. Some require github experience to get started. They more further away from WYSIWYG editing. While static sites offer increased security, faster load times, and reduced server costs, they suffer from the upfront editor experience.

On the high-end of the market headless CMSs go even further in over-complicating the separation of content and look and feel. In theory we should be able to author clean markup with few semantics and the elegance of CSS’s zen garden should allow us to make sites look and feel however we want. The reality is that none of these tools provide clean separation because the underpinnings of the protocol and language prevent that. While I’m happy to have migrated these three sites to be static, I’m once again appalled at how bad HTML and CSS are.

This post is licensed under CC BY 4.0 by the author.