In Defense of Static Sites
summary
Argument: most public sites need no backend or heavy JS, so choose static when content is informational, cheap, fast, and secure. Cites concrete pain: two and a half hours fixing local npm tooling and an ecosystem of 437 generators; concrete wins: simple deploys like upload to S3 and fewer ops/security issues; concrete workflow: use APIs at build time and rebuild in a minute (Middleman/Jekyll + scripts). Use static for portfolios, blogs, events, prototypes, marketing; upgrade later if users require runtime state.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:12Building things to build things
- 6:22Focus on users
- 8:02Distractions
- 11:12CSS
- 14:15Pros Cons
- 15:47How to Decide
- 17:21Use Cases
- 20:38Building
- 21:20Choosing Static Sites
- 23:20Upgrading
related talks
32mStatic Sites go all Hollywood
43mHow to simplify your life by embracing static site generation
14mStatic Site Generators with JavaScript
19mStatic websites - The Final Frontier
24mThe Performance Aspect of Building and Deploying Static Sites
28m⚡️ FEDC 2018 - Chris Coyier
19mA Skeptic’s Intro To The Jamstack
52mBACK to the Future: Static Blogs and Websites with Jekyll