Killring Rick Dillon's Weblog

The Power of Static

In the beginning, there were static web sites: sites that served documents, because that's what the web was designed to do. Hyper text transfer protcol is document-oriented, as is the hyper text markup language. But the web became increasingly dynamic, with new sites requiring that documents be generated on-the-fly, which necessitated the use of databases. Weblogs came along, which are nothing if not document-oriented, but they tend to use dynamic technologies like databases anyway.

But there has been a trend lately towards blogs that are static. At first blush, a static blog, which is really nothing more than a collection of files in directories, seems inferior in most every way to its dynamic counterpart. {"Why would anyone use a static blog when engines like WordPress are so ubiquitous?"} <!--more-->

On The Plus Side...

So, what's cool about static?

Cheap Hosting

Cheap hosting is cheap because it requires no dependencies (special runtimes, databases, web server plugins, or caching); it is easy to drop a bunch of files on a disk and serve them. It also doesn't require much CPU time to serve them, so hosting can be cheap. GitHub or Amazon S3 (either directly or through an insanely simple service like Staticloud) can be used to serve a static blog for free or almost-free.

Good Security

Since there is no backing database, no passwords to an "Admin Panel", and no SQL queries, static sites are just about as secure as it gets while still serving a webpage. Similarly, there is essentially no need to update the software associated with your site: your hosting provider will likely be taking care of updating the operating system and server software, and there is no software beyond that.

Good Scalability

Originally, this was going to be a post about functional programming as applied to scalable web hosting. Along those lines, it probably suffices to say that the hard problems in scaling websites occur when data changes over time. For any given version of a static site, there is no change over time, so it is easy to stand up mirrors and load balance among them. That's why when sites get Slashdotted, they often create static versions of the pages under demand and serve those until the storm passes: static scales.

Future-Proof Data Format

If you're hosting your blog with services like Posterous, Blogger, Typepad, Moveable Type, SquareSpace, or WordPress, you inevitably will have to face how you want to get your data out of those services. There is no real standard on how blog data should be organized, so moving from one service to another is fraught with complexity and error. If you use static hosting, the data is, by definition, in a standard format: that which browsers can render (usually HTML + CSS + JavaScript). Aside from ASCII (or UTF-8), that's about as future-proof as it gets in the computing world.

Trivial to Mirror/Backup

If your hosting provider loses your data, or you want to move it to a new host quickly, nothing is better than a static site. With a tool like rsync, it is trivial to keep lots of mirrors in sync, or keep a backup on your home machine. In fact, a common method for creating a static site is to use site-generation software on a desktop, and then rsync the output to a hosting service. This methodology guarantees that an entire copy of the site is in at least two places.

Easy to Test

Sometimes, as you're writing content, you want to preview the result. While dynamic sites allow for this to varying degrees (for example, some support previewing posts, but not previewing site template changes), static sites are ideal: the entire site can be rebuilt offline, and when it is fully tested, it can be atomically pushed to the hosting service (probably a topic for another post, but file-based content can be atomically switched by hosting a symlink, so when all the new content is uploaded, you flip the symlink over to the new content and delete or archive the old).

And On The Not-So-Plus Side...

It's not all roses. Just like functional programming, sacrifices must be made.

Comments and Search

Since you can't have dynamic content, you'll have to outsource any dynamic features. For a blog, the two most obvious uses for dynamic content are comments and search, although some blogs also offer a "Contact Us" form that accepts a POST that sends an email to the blog owner. The good news is that these are easy to outsource through services like Disqus and Google's Custom Search Engine. The bad news is that, at least in the case of Disqus, you then end up outsourcing part of your content (the comments), and for that content, you lose all the advantages listed above.

The only other point I'd make here is that, at least for me, I don't mind having a blog that doesn't support comments, since the trend in social networks seems increasingly centered around the notion that the social experience is a layer built on top of existing sites. Thus, there might be a discussion on Google Plus about one of my posts, and perhaps one on Facebook as well. Even a static blog can facilitate that sort of discussion through the use of JavaScript that allows users to support, share and comment through those other services. There are sacrifices there, to be sure, but it relieves me from having to deal with comment spam and database administration.

Online Authoring and Editing

Most bloggers are quite used to the idea of authoring their posts inside the web browser itself. If you step back, the notion is fairly novel: the tool in which the content is consumed is the same as that in which it is created (this isn't true for most media, like photos, music, movies, games or books). Having the authoring tools embedded in the blog itself allows users to blog-on-the-go, and doesn't require any kind of local setup.

Without wanting to be too elitist, this also has the side effect of dooming most bloggers to use mediocre editors.

Blogs Serving Multiple Users

While it is possible to use a system like Jekyll or Octopress to host a blog for multiple users, it isn't nearly as straightforward as a product that has multi-user functionality baked in.

Static?

So is static right for your blog? If you're like me, probably.

  • I don't get a lot of readers, so missing discussion features isn't a big loss
  • I do value being able to blog offline and fully test the site before I roll out a new version
  • I create content much better in Emacs than I ever could using a web-based editor
  • I often embed source code in my posts, and having to use an external service to host code snippets (like GitHub's Gist) seems like overkill.
  • I'm fairly tech-savvy, so using Octopress + Emacs + rsync to blog is quite natural for me.

Thoughts? Let me know over on Google Plus!