Somewhere between 2015 and 2020, the web development community collectively decided that serving HTML files was too simple to be taken seriously. The static site became unfashionable — acceptable for personal projects, perhaps, but insufficient for anything real. Everything real needed a framework, a build step, hydration, client-side routing, a node_modules folder measured in gigabytes. The frameworks were impressive. The deploys were complicated. The sites were, in many cases, slower.
The static site has been rehabilitated since, partly by the JAMstack movement and partly by the dawning recognition that client-side rendering has real costs — in performance, in SEO, in accessibility, in the complexity budget of small teams. But the rehabilitation has mostly been about static-ish sites: HTML generated at build time by JavaScript tools. The genuinely static site — files you can open directly in a browser — remains culturally undersized relative to what it can actually do.
What Static Actually Gives You
A static site served from a CDN is fast in a way that server-rendered applications fundamentally cannot match: there's no origin server to reach, no database to query, no runtime to initialize. The file is already compiled; the CDN is already close. Time to first byte approaches the speed of light over fiber. This isn't optimization — it's the architecture being naturally aligned with how HTTP works.
Static sites also age differently. A React application from 2019 may require significant effort to run today — dependencies have changed, Node.js APIs have shifted, the toolchain has moved. An HTML file from 2019 opens in a browser with no modification. This longevity isn't trivial: for content that's meant to endure — documentation, archives, portfolios, reference material — the maintenance burden of a dynamic stack compounds over time in ways that static files don't.
"The most durable technology on the web is HTML. That's not a consolation — it's a design principle."
When Static Falls Short
Static sites have genuine limits. Personalization, authentication, real-time data, user-generated content — these require server involvement at some layer. The JAMstack approach of pushing this to edge functions and third-party services is viable and often the right call. But "use a static site where it works" isn't the same as "never build anything dynamic." The mistake is applying dynamic architecture to problems static sites solve better, not the reverse.
For most marketing sites, documentation portals, portfolios, and content-first publishing platforms, static is the right default. The question to ask is: does this page need to be different for different users, at request time, based on server-side data? If no, static wins. If yes, evaluate what the smallest possible dynamic surface is, and keep everything else static. The frameworks will keep changing. The web platform has been backward-compatible for thirty years and shows no sign of stopping.