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?
On The Plus Side…
So, what’s cool about static?
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.
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.
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
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.
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
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!