One of the options, when I started looking around for an alternative to my home-brew blogging engine back in 2003/4, was Movable Type. It generated static files each time you hit publish. It was slow and seemed a little antiquated, so I opted for WordPress (then at version 1.2, which shows how long I’ve been using it) because dynamic was obviously the future.
Static is Back
There’s been plenty of noise about the re-rise of static sites lately, mainly due to Static Site Generators — software or engines that take content (often in Markdown format) and some templates and generates plain old HTML files.
There are a number of benefits to this approach that seem to be appealing:
- You can host it anywhere, every web server and host supports HTML
- Fewer security concerns to worry about
- No upgrades to install
- You can create process flow for versioning and deployment
- You can write content in your favourite text editor
- Speed
It’s not like static site generators went away, but with the growth of services that can now be delivered on the front-end (dynamic content, comments, etc) they’re re-emerging as an alternative for certain types of sites.
Making a Move
I had no real reason to change any of my sites to static code. I have knocked up a couple recently that pull content from a JSON file and display it using JavaScript templates — largely because they were simple and gave me the chance to play with some new stuff — but all my other sites (those consisting of more than a couple of pages) run on WordPress. I’m familiar with it, I can bend it to just about anything and it works.
One reason to make the switch was simply to try a new technology, one that seems to be gaining traction. Another was to try some alternative ideas with regards to hosting. I’m not unhappy with my host but there seems to be an ever-growing collection of alternatives to traditional hosting, so I thought it was worth a play. One of my smaller sites is hosted on Github Pages, for example.
Choosing an SSG
There are plenty of options when it comes to static site generators (see here and here), and that’s before you consider static CMS options. There’s several in every language you can imagine (and even the option to use WordPress to generate static pages). Jekyll is probably the best known, being heavily integrated with Github and therefore the talk of developer’s circles. I looked at a lot of options before deciding on Hugo.
Why Hugo?
One answer is it’s simple to install and run, It consists of one executable that can run on any OS. I didn’t need to install a new interpreter (e.g. Ruby) or server (e.g. Node.js). Hugo also has great documentation (I can’t overstate how important that is to your project), which helps lower the barrier to entry.
That’s not to say I was 100% happy with Hugo. I would have preferred something that used one of the template languages I was already familiar with (to save another learning curve), such as Jinja2 or Handlebars, but it uses Go Templates. I’m also unfamiliar with Go, so writing plugins (should I have needed to) was probably off the cards (in the short term at least).
None of the options I looked at were a perfect fit either and I kept coming back to Hugo.
The Process
I can’t say it was seamless, but with some head-scratching, plenty of web searches, and a few hunts through the Hugo community forum, I managed to turn my WordPress template into a Hugo theme and go static. You can see the results here.
There was certainly a learning curve. There’s some room for improvement in the documentation (I plan a ‘tips’ post shortly) and the structure (of themes specifically) could be clearer and easier. Overall it wasn’t too bad though.
The Drawbacks
There are some drawbacks to going static, obviously. Hugo doesn’t auto-resize the images (something that is coming) so I had to spend some time manually creating some for each page that used different ones. I also lost the ability to auto-tweet my posts, which I do with most of my sites. Site search was another casualty (I could have implemented a custom Google search).
I ended up writing some front-end code to help create a simple gallery from my Markdown code (I may have be able to use shortcodes in Hugo, but elected not to as it would have meant remembering more random syntax).
There’s no WYSIWYG editor, although I do get to write in Markdown, which I’d already been using more and more. Rather than just hitting Publish, you also have to manually run Hugo and upload the generated files.
Hugo is a command-line tool though, so people have been using things like Grunt, Gulp and other deployment tools to automate this process. You could even write your own, in whatever language you preferred. You won’t be able to do it from any web browser though, like WordPress.
This makes it hard to recommend to less technical people, although these hurdles (speed bumps) aren’t limited to Hugo. The SSG community is already providing solutions to many of them.
Final Word
I’m pretty pleased with how the process went and what I ended up with. Static site generators aren’t for everyone, but they’re certainly an alternative, and one I think we’ll see more of, especially from agencies where ongoing maintenance and security concerns, not to mention hosting costs, are of interest.
So have a look, find one that you like the flavour of and roll away. It may not be the only option, it may not always be the best option, but static is back.
