The Static Site Paradox Permalink

Loris Cro:

In front of you are two personal websites, each used as a blog and to display basic contact info of the owner:

  1. One is a complex CMS written in PHP that requires a web server, multiple workers, a Redis cache, and a SQL database. The site also has a big frontend component that loads as a Single Page Application and then performs navigation by requesting the content in JSON form, which then gets “rehydrated” client-side.
  2. The other is a collection of static HTML files and one or two CSS files. No JavaScript anywhere.

If you didn’t know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it’s actually the inverse: only few professional software engineers can “afford” to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions.

For №2 to be successful for “normal” users I think there needs to be an approachable UI to be able to make changes on the fly… and the implementation gets complicated quickly if you’re doing it on the website itself.

The funny thing is that we we had such a thing in the early days of the web: native apps for authoring a website and uploading it, such as Frontpage, Dreamweaver, or Netscape Composer. It’s strange that these seem to have fallen out of favour now.