Web servers & CMSes, what runs the site you're about to build.

Section · 01

A web server, demystified

The word “server” means two things and they get confused constantly. Hardware: a physical or virtual machine running 24/7 somewhere. Software: a program on that machine that listens for HTTP requests and answers them.

The most common web server software you'll see:

Nginx       — fast, static-friendly, also a reverse proxy
Apache      — older, plugin-rich, classic LAMP stack default
Caddy       — modern, automatic HTTPS, sane defaults
Node.js     — JavaScript can also be a web server (via Express, Next.js, etc.)

Your laptop can run web server software too. When you run npm run dev on a Next.js project and visit localhost:3000, you’re a client making requests to a web server you started thirty seconds ago. The only difference between that and yorksims.com is what address it’s listening on.

Section · 02

Static vs dynamic content

Static: the server has a file on disk and sends it as-is. Same bytes for every visitor. Fast, cheap, hard to break.

Dynamic: the server runs code to build a response on the fly. Different output for different users (their name in the header, their cart, their search results). More flexible, more expensive, more ways to break.

Static:    GET /about.html  →  read file  →  send file       (5ms)
Dynamic:   GET /cart        →  check session → query DB → render → send  (200ms)

The modern trick: pre-render

Most sites are mostlystatic with a few dynamic parts. Modern frameworks (Next.js, Astro, SvelteKit) let you build a page once, save it as static HTML, and only run dynamic code for the bits that genuinely need it. You get static-fast performance with dynamic-friendly developer ergonomics. This is what “static site generation” (SSG) and “incremental static regeneration” (ISR) are about.

Section · 03

What a CMS is for

A Content Management System is a web app whose job is to let non-technical people edit a website. You log in, click around in a UI, write a blog post, hit Publish — and the CMS handles storing it, rendering it, and serving it.

The popular ones:

WordPress    — 40%+ of the web. PHP. Endless plugin ecosystem.
Shopify      — e-commerce-specific CMS. Hosted, opinionated.
Webflow      — designer-friendly visual CMS, generates clean HTML.
Sanity       — headless CMS — provides only the data + editor, you bring the frontend.
Contentful   — same idea as Sanity, more enterprise-leaning.
Ghost        — focused on writers and newsletters.

The CMS’s tradeoff: you trade flexibility for speed. A CMS site you can build in a weekend; a custom codebase takes weeks. But a CMS site has limits a custom one doesn’t.

Section · 04

Headless vs traditional CMSes

Traditional CMSes (WordPress, Shopify) ship the data, the editor, AND the frontend together. The same software that lets you edit a post also renders the post for visitors.

A headless CMS (Sanity, Contentful, Strapi) ships only the data and the editor. You query it via an API and render the result in whatever frontend you want — Next.js, mobile app, smart fridge.

Traditional:   Editor ↔ CMS (WordPress) → renders HTML directly
Headless:      Editor ↔ CMS (Sanity)    → JSON API → your frontend renders

Headless is more work upfront. It’s worth it when you have multiple frontends (web + mobile), or when you want full control over how content gets displayed.

Section · 05

Which one should you use?

Boring but honest answer: it depends what you’re building and who edits it.

A marketing site with 5 pages         →  hand-code in Next.js or Astro
A blog you'll update weekly           →  Ghost or WordPress
An e-commerce store                   →  Shopify (full stop)
A content app with multiple frontends →  Sanity or Contentful + Next.js
A side project for yourself           →  Next.js + Markdown files
A client site where they want to edit →  WordPress or Webflow

The mistake new devs make is reaching for a CMS when they don’t need one (slower, more attack surface, more dependencies). The mistake new founders make is notreaching for one (now they’re paying a dev to fix every typo).

Section · 06

Where this lesson lives in the stack

So far in Unit 1 we’ve gone: history (lesson 1) → how packets move (lesson 2) → how names become addresses (lesson 3) → what’s actually on the other end (this lesson). You now know enough about the plumbing.

The next three lessons shift from the network to the design and process: wireframes, responsive layout, and dev workflow. Then Unit 2 puts your hands on the markup — HTML and CSS.