The Static Site Paradox

Original Article ↗ Hacker News Discussion ↗

Static websites promise speed, security and cheap or free hosting, yet most non-technical people still gravitate toward heavier platforms like WordPress. Commenters debate what “static” should mean, weigh the trade-offs between static site generators and dynamic CMSs, and repeatedly return to one core reason for WordPress’s dominance: its WYSIWYG editing, plugins and built‑in features (comments, forms, ecommerce) make content management far easier for normal users than Markdown files, Git and custom build pipelines. Several argue that until static-site tooling offers equally simple authoring and collaboration, complexity-heavy solutions will continue to win despite their technical inefficiency.

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.