Back to Static

When an update/redesign turns into a full-scale migration that takes us a lot closer to our roots than expected.

4 minute read

As you might be able to tell, my last blog post is from 2014. It was about time to get back on the blog horse but also give the site a little facelift. I’d migrated blog platforms in the past, but never really took the time to think about how my own personal site was hosted. So let’s take a quick trip down memory lane.

Static Site (2011)

When I first got into web development (professionally), I thought it’d be cool to build my own website from scratch to prove my mettle. That was 2011; certainly not far enough ago by any means for most of the technologies in use today to not exist. But, I was young and naive, and had some big ideas (e.g. a live CSS switcher, replicating the exact same look/behavior with and without Javascript, etc).

I learned very quickly from that experience that keeping a static site up to date was really difficult. Any time you made a change one place, you had to make sure you made it everywhere. You had to make sure to manage collisions. You had to handle your own deploys and routing. It was a hassle, and I virtually never updated the site, so after spending some time working with ZebraDog and seeing the power of Drupal, I decided it was time for a change.

Drupal 7.0 (2012)

So I set out to update and re-design the website again, this time using something a little more powerful and modern, and to make it easier for me to create new content while still having full control and flexibility over how it’s displayed and what functionality the website had.

After all, at ZD we’d built a lot of things on Drupal, ranging from fairly simple real estate websites to fairly complicated institutional websites to the backbone of interactive multimedia installations. I could use it to build a measly blog and portfolio website, right?

The problem wasn’t whether I could; in fact the problem was probably that I could. I built an incredible media delivery site that was isolated from the world and almost too powerful for its own good. Developing and maintaining the site was nontrivial, and adding new content, while certainly easier than a static site, was beyond me.

Back to Static (2016)

Blog technology philosophy has shifted lately. WordPress is still the clear winner in the space, but there’s an alternative to generating the site every time it’s requested. These take the form of static generators, and make a lot more sense to me personally. Jekyll, Ghost, Hugo, Hexo; the list goes on. What’s under the hood doesn’t really matter (which, as an aside, makes switching way easier) — all that matters is the static HTML/CSS/JS they output.

It seems a little weird to be going back to a static option, but there are some major differences:

  1. I have so much less to worry about in terms of upkeep and deploy thanks to things like partials and services like Aerobatic.
  2. Content creation is way easier because I literally create a file and start typing. Markdown gets translated into HTML and all of the formatting and styling is handled by the templates I define.
  3. I stand on the shoulders of giants — there have been tons of people putting in tons of work to make things like this easier. There’s no reason to reinvent the wheel.

So (and I’ve said this before), theoretically keeping the site updated will be a lot easier. I somewhat feel like a cop-out for using a fairly standard template/look-and-feel, but at the end of the day, my job as a designer isn’t to make things look pretty or to be unique. My job is to provide the best experience possible for my users. In the context of a blog, that means engaging, useful content; not pretty pictures.

All Development posts: