The Static Site Paradox

Original Article ↗ Hacker News Discussion ↗

Definition of “static website”

  • Ongoing disagreement about what “static” means.
  • One camp: “static” = no server-side generation; flat files that any dumb file server (even cat index.html) can serve. Client-side JS is OK.
  • Stricter camp: “static” = no scripting at all (neither server nor client). JS-only apps that hallucinate content are seen as “not really static” or aesthetically wrong.
  • Another view: a static site should work when opened directly from the filesystem or mirrored with wget.
  • Many distinguish between hand-edited HTML vs. content compiled from markdown/templates; both often still called “static”, just at different “degrees of staticness”.

Static vs. WordPress / CMS / Dynamic stacks

  • Static sites praised for durability, ease of copying, cheap or free hosting (GitHub/Cloudflare Pages), and minimal maintenance.
  • Critics note the “static site paradox”: technically simpler architecture, but more complex for normal users to set up (domains, hosting, deployment, Git, tooling).
  • WordPress and similar CMSs win for non-technical users: one-click installs, WYSIWYG editing, plugins, built-in comments/contact forms, and upgrade paths to shops, memberships, etc.
  • Some argue WordPress is overkill, insecure, slow, and often badly maintained, yet its plugin ecosystem and ease for editors outweigh those drawbacks for many.
  • A recurring middle-ground idea: author in WordPress (or other CMS), then export to static files or heavy caching to approximate static behavior.

Editing experience and collaboration

  • Major pain point: SSG workflows (Git, markdown, CLI, shortcodes) are daunting for non-engineers and teams.
  • Static advocates enjoy text-based, version-controlled editing; but colleagues (marketing, clients) prioritise quick, visual editing and autonomy over performance and purity.
  • Multiple comments stress that site technology is usually chosen by the people who manage content, not developers or readers.

Interactivity: comments, forms, extra features

  • Static sites become awkward once you need comments, dynamic contact forms, categorised submissions, or advanced features.
  • Solutions include third‑party services (Disqus, Netlify forms, ActivityPub, GitHub Issues, custom backends) but they add moving parts and bills.
  • Some think comments are less essential now, as discussion happens on external platforms; others still value on-site comments highly.

Performance, resilience, and broader reflections

  • Many value static or low‑JS sites for speed, low bandwidth, and resilience—highlighted by disaster scenarios where heavy sites failed on weak 3G.
  • Others argue that for most businesses, time and cognitive cost for humans matters more than machine efficiency; they’ll pay for systems that “just work”.
  • Several see the real problem as web tools failing to make simple publishing truly straightforward for ordinary people.