My earliest website was an embarrassment in neon type, non-uniform image sizes, and gratuitous DHTML (Javascript + HTML/CSS).

The workflow – writing HTML/CSS in a text-editor, and CPanel upload to the shared hosting provider – had an offline-online divide.

Blogspot and wiki.dot – with their WYSIWIG online editors – replaced this with a sync problem. How does one know that they have the latest version backed up?

Packages like XAMPP (Apache, MySQL, PHP) offered a sync solution: replicate the server environment and write on your local, then publish when ready. But managing an entire server stack locally proved painful.

Bridging the online-offline divide

Most websites simply serve static pages - leveraging CDNs (edge servers located close to user groups) to do so.

Two trends merged to give rise to a new workflow in web-publishing:

  1. Git: a distributed code versioning system that lets you work with a repository while offline
  2. CDNs: added static site generation tools to their offerings

This enabled a workflow that lets you:

  1. manage your website as a Git repository
  2. hook a CDN’s static site generator service into your Git repo, to automatically build and publish your site to a web server

I decided to clean up my neglected online offspring – blog, wiki, google site, self-hosted WordPress, and Linkedin blog – and consolidate using this strategy. No more grappling with, ‘Which one is the latest copy?’.

Why?

  1. innate match with a digital garden: you control what is published, while tending to germinating ideas in a private nursery.
  2. Markdown: an open format that frees you from vendor dependency, while having excellent tool support - Obsidian for editing, pandocs for translation. When we use a word processor, the focus often shifts to typography rather than structure. Markdown helps bring structure to your writing by stripping it of typographical fluff.
  3. Ontologies: with Productivity suites, the tendency is to encode ontologies in complex folder structures of topic and sub-topic. The metadata approach to managing ontologies – through frontmatter on a Markdown file – lets you have what is imo a more integrated and manageable ontology encoding.

Traditionally, there are two types of websites:

  1. Static sites that lack enterprise-level features (security, scalability) and lack significant interactivity
  2. Dynamic web applications where interactivity is driven by a backend (be it scripting modules on an HTTP server such as CGI/Python/PHP, or an enterprise Java App Server.

Static implies no programming in the traditional sense. The infrastructural burden of managing a database and web server that exists in a traditional 3-tier application, is replaced by using REST APIs as the backend. The API provider manages the infra.

Around 2014, an alternative style for developing static sites that incorporated dynamic behaviour gained popularity. The founder of Netlify christened this the Jamstack in 2015.

Jamstack website publishing workflow

Jamstack brings a developer-centric workflow to web publishing, bridging the online/offline divide:

  • Site content is created as markdown, and stored in a Git repository.
  • Git Hooks enable a CDN provider to tap the events in your repository
    • whenever you push a change to the Git server, the SSG supported by the CDN will pull those updates from the repo
  • the SSG will trigger a build and publish your site on the CDN

Git: a distributed code versioning system.
Your code and repository exist on your local machine – so you can work offline.
When ready, push your updates to the remote server (online Git repository).

Content Distribution Network (CDN): a network of edge data-centers that offer low latency distribution of content to end-users. Edge simply means data centers close to dense regions of population, i.e. close to the audience.
Jekyll is supported by both GitHub Pages & Cloudflare Pages. The latter purportedly offers free SSL, and works with private repos. Though it does nudge you to opt-in to their more recent serverless offering called Workers Site. At first sight it looks as if Workers does not support Jekyll SSG in the build process. That might mean one needs to generate the static assets offline and configure Workers to deploy them?

Blogroll