It warms my nerdy heart to think about how much of my Internet presence is static content. I remember the early days, when you’d
ftp a bunch of
html files to a server and run some httpd to blast them out on demand. It was conceptually and architecturally elegant. It was stateless.
It wasn’t enough. In the mid-90s, Netscape developed the cookie specification, which gave us pragmatic1 cross-request statefulness for the first time. A thousand shopping carts bloomed, and with them many new stateful architectures took hold. Tools like WordPress gained traction, turning what were once static affairs into database-backed content management systems.2
Today, the pendulum is swinging back. Much of what was once static is static again, only this time it’s built on far superior tools. We have:
At the same time, a new host of web standards — most notably W3C Web Storage — has dramatically increased the scope of what’s possible in a “static” site. If your service doesn’t need to maintain state across clients, it’s absolutely in the static wheelhouse.
Best of all, we have well-structured and highly portable content. I don’t mind serving my blog with bespoke tools like CloudFront; if Amazon vanishes tomorrow, it will take zero time for me to find an alternative. In the ever-changing world of the web, that’s something I can hang my hat on.
 It’s of course possible to communicate state by marching a browser through a structured URL space. But for certain kinds of statefulness — logins, shopping carts, etc. — this could never be suitable.
 Movable Type was always a curiosity to me: a static site generator backed by a SQL database, rather than a filesystem.