Dave Peckdavepeck.org

Static Sites

June 1, 2014

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:

  • Powerful generators, like Jekyll and a hundred others, that produce static content from complex asset pipelines

  • Cloud infrastructure, like S3/CloudFront and GitHub Pages, that cost-effectively serve static content at scale

  • CSS and JavaScript frameworks aplenty that make our content vastly more attractive

  • Workflow tools like Yeoman and Brunch to help us tie the pieces together

  • Nascent services like Forge and Brace that aim to make serving static content possible for essentially anyone

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.

[1] 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.

[2] Movable Type was always a curiosity to me: a static site generator backed by a SQL database, rather than a filesystem.