Resonance Dev Gone Static
  • Resonance Dev Gone Static
  • By: Ryan Palmer
  • October 01, 2013
  • Our company website has been powered by Drupal since Resonance Development was incorporated and this domain was registered on December 18, 2008. Fortunately for me, Drupal 6 had been released earlier in the year, and with lots of runway ahead of us, upgrading hasn’t been a necessity. This site would have been supported until Drupal 8 is released sometime in 2014, as long as I kept the server online and stayed on top of Drupal security updates.

    It goes without saying that I should spend more time creating new content, updating our portfolio (stale for years by times), adding team members, etc. But even given a modest blogging habit and other content changing a few times a year, the features of a full-blown CMS are somewhat lost on us.

    There are a few benign realities of maintaining a mostly-static web site in Drupal:

    1. It’s easy to forget “how” you’ve built something. For any given Drupal vintage, the preferred method du jour of accomplishing almost anything outside Drupal core functionality changes constantly.
    2. The utter lack of interest in managing security updates. As long as there are no public forms or open registrations or logins, the risk of not applying security patches is extremely small.
    3. The further lack of interest in upgrading major versions for the sake of upgrading alone. It’s very difficult to make the business case for doing so, unless it’s for security (see above).
    4. No reason not for it to be extremely performant (everything is cacheable as a whole), yet as a CMS-powered site, it will never be that fast.
    5. It’s hard to justify paying any money to host such a site, yet shared hosting is not attractive either. Site outages are an embarrassment, especially for simple projects.

    Yet, we find ourselves of maintaining brochureware site in a CMS because we desire to keep our content structured (often in a database), we need a templating solution, require some degree of content reuse across pages and sections, we need some web forms, RSS feeds, and it looks like a nail, damnit. And we’re left with something that does need ongoing care and feeding because the Internet can be an unforgiving place for unmaintained software.

    No more. We are drawing a post-CMS line in the sand for the sake of simplicity. We’ve going static with the help of Jekyll like plenty of others before us.

    The truth is, it’s not a big jump for those already comfortable with a few basic tools of web development. Git and GitHub are used for versioning and distribution (and in this case, free hosting). Site data is stored in YAML and content formatted with Markdown. Working knowledge of front-end concerns (HTML/CSS/JS) is assumed. You can use for editing content if you like, but we don’t bother.

    Going static means working within a tighter set of constrains than we’re used to, but it makes for cheap or free hosting, zero security concerns ever, no threat of CMS obsolescence, and a codebase that is simple enough almost anyone could modify or extend. You could say the exact opposite about our former Drupal site.

    Running an otherwise static website is a challenging paradigm shift, but anything lost on the server side can often be made up client side with JavaScript. Talk to us today to find out if a post-CMS solution could play a role in your web portfolio.