You Want A Static Website

Jun 11 2009

If you are like me, you are a programmer, with enough technical ability to understand what the web is made up of. Being techies, we should probably consider building a website. Just not a dynamic one. You don't need it, unless you're going to dedicate a certain amount of time maintaining it.

Dynamic Anything Means Maintenance

My own personal website was never taking off. What would happen:

I'd get really tired one day, and kind of bored, and would write something.
3 months later I might write something else.
When I go to update the site, I'd start to update something, and spend far more time updating than writing.

Sometimes it was a security patch, sometimes it was a fancy new feature and I'd just have to check it out.

Repeat After Me: You Do Not Need It

First, YAGNI comes into play here. Unless it makes you money, it's only value is learning, or a distraction. It can be hard to deal with both. And if all you need to do is learn, for God's sake don't make it public. You can leave it on your home network.

The value of learning how your hosting provider of today makes your deployment life hell will be useless in 3 years. Because by then some other piece of web hotness will have become the de facto standard of deployment, make everyone's life easy.

We Are Not Journalists

In the end, if you just consider what kind of content you need, well, you'll likely end up with a bunch of static data. You know, thoughts that are probably poorly organized (if you're like me), but, timeless. As in, not news. So why use anything dynamic?

If you end up with a bunch of static files that have to be served by apache version 1.2, and then you move to another server with IIS or Apache version 2, your files will likely never change.

And maintaining static data is a lot easier than dealing with app upgrades.

Simple Performs

If you stick with static, it's going to take far fewer resources to host the site. This means you'll never get remotely close to your hosting provider limits, unless you get linked to something cool. In which case, you have the worlds easiest "scaling algorithm" : find a faster cache, and then copy your files there.

Choose The Right Static Format

HTML is not the greatest static format for written ideas. It was really meant for machines to talk with each other.

It's awfully hard to read, especially if you're writing in a non-english language.
The specification changes, there are lots of bugs in rendering that get fixed, etc.

Most website generators use some kind of text-based format, which is then translated into HTML. My personal favorite is Markdown. There are many others, but all will be better than HTML, provided:

They are widely supported.

You understand how to convert them. (It's usually a 1-week side project.)

The best part is the understanding to convert them, because then you can get into "website bliss" : using conventions to build up a simple site.

What About Integrating my other sites?

If you've got content strewn about many other applications, well, it's probably a good idea to have your site aggregate all that other stuff. Provided those other sites have APIs, it's not to hard. But let's take a look at some common possibilities:

Now, before you try to add server backend that loads this stuff dynamically, stop. Then write down how often you post to those sites. Likely, it's less than 10 times a day.

My sense, is that you probably will have to manipulate the presentation anyhow, so you're going to have to manipulate the content coming off of those other sites -> somehow. This means building up a separate store of the content.

But since you update so rarely, I'm willing to bet you can build something that will process and generate index pages, manipulate images, etc., in less than 1 second. The transfer rates of getting your updates will absolutely dwarf that. So...

KISS And Poll

By polling for updates at a periodic interval (like every hour), you'll probably be as up-to-date as you need.