An Introduction to Jamstack

Web Development Evolution

The World Wide Web (WWW) was born in 1991 with Tim Berners-Lee inventing HTTP, HTML, and the first browser/server at CERN to share physics data.
Then in 1993, Marc Andreessen, an undergraduate at the University of Illinois in Urbana-Champaign, created the Mosaic browser and suddenly the web exploded onto the scene as a killer application.
The siren call of a owning a shiny piece of digital real estate has echoed ever since.

Killer App: a compelling technological use-case that acquires accelerated critical-mass adoption.
Spreadsheets and word processors were the killer apps on IBM-PC clones in the late 80’s.

The explosion of the Web led to the rise of dot com boom of late 1990s and companies like Netscape, Yahoo!, Amazon.com, eBay and Google.

On the web development side, the earlist web-masters dealt in plain HTML – going berserk with neon-coloured type.
Javascript (1995), and CSS on its heels (1996), launched the Dynamic HTML (DHTML) wave.
Ajax libraries like Scriptaculous, Prototype and Dojo, solidified this into Rich Internet Applications (RIAs). The era of RIA saw browser plugin and client-side runtime frameworks come and go (Macromedia/Adobe Flash, MS Silverlight, JavaFX).
And then, the Web standardized around Html5.

Along the way, personal web publishing, rode a wave of online services such as free WYSIWIG services: websites on Xoom or Google Pages, blogs on Blogspot, and wikis on Wikidot.
More complex websites for content publishers were built around content management systems such as Wordpress. This required a LAMP (Linux, Apache httpd, MySQL, & PHP) stack – a web server with a scripting language module, and database, with scripting languages ranging from Perl (mod_perl), Python, and Ruby, to ASP on Windows.

Economics (time and money) led to the rise of the shared hosting model where infrastructure such as bandwidth, database and web servers are parceled and rented by Internet Service Providers (ISPs) in packages. You could host your own website using annual packages that offered say, 1GB monthly bandwidth, a single database, and scripting language supported.
All this could be managed using the de facto CPanel interface.

With so many options it is not unheard of, for folks to have a long tail of sites fallen to neglect: blogspot, wiki.dot, Google Site/Pages, self-hosted WordPress with custom domain, and LinkedIn blog.

Enterprise application stacks are very different – relying on JavaEE Web Containers (Tomcat), or Application servers – JBoss/Wildfly, BEA/Oracle Weblogic, IBM Websphere.

The online/offline workflow problem

The majority of personal and small business websites are static sites about content publishing.
Whether a plain HTML site uploaded via CPanel, or an online service – with content comes the sync question: ‘am I looking at the latest copy?’
One usually wants a synced offline dump for editing and ownership.
For services like Wordpress, an XAMPP (Apache, MySQL, PHP) stack offered a solution by replicating the entire server environment on your local machine, and publishing it to an online mirror service. But this proved painful to say the least.

Jamming a solution

Problems such as these led to (around 2014) a ‘what-if’ fueled alternative for static site development.

A few technical innovations enabled this movement:

  1. Git: an open-source distributed versioning system (helps resolve: ‘am I looking at the latest copy?’)
  2. Static Site Generators: Tools that use a templating language for building a website. They consume Markdown (with directives in the front-matter) as part of their build process. An SSG does not rely on a DBMS or a server side scripting language.
  3. CDNs with SSG support and Github integration (you commit your content to Git, and the CDN uses a hook to pull that update and publish it using an SSG framework integration)
  4. service providers launching APIs to access their services on the web for anything from Comments management (Disqus) to database management (Supabase). These serve as the building blocks for data-driven services.

No more manual content syncing required. The latest copy is always in your Git repository.

Jamstack: Javascript, APIs, Markdown

Around 2015, Jamstack gained traction as the moniker to anoint this new way of building static sites with dynamic behaviour.

The static page content itself, is written in MarkDown – an open, universally supported format, with excellent tools like Obsidian, and converters like Pandoc. Markdown brings a focus to the content structure rather than typography in WYSIWIG editors.

The ‘static’ in SSG implies a move away from runtime server-side processing and the use of databases to create a dynamic website. The burdern of managing database and web servers in 3-Tier web applications, moves to the API provider in Jamstack. A static website consumes REST APIs in lieu of a backend.

Jekyll

Jekyll is a popular SSG written in Ruby, and is available as a library aka Ruby gem.

It uses the concept of processing directives in the Liquid templating language, embedded in the markdown front-matter such as this, which tells the SSG what layout to apply to a page for instance:

---
layout: default
---

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?