Static Site Generators and Hugo

Static site generators have been a hot topic in web developer circles for a while now. Just like any other software tool, static site generators can offer a great solution to specific problem. But what is that problem, and who needs to solve it?

What is it?

At the risk of over-generalizing, SSGs recall the simpler days of web sites when the only technology required was HTML and CSS files, and maybe some client-side Javascript. No runtime languages, like PHP or Ruby are required. No database is involved in serving pages to the end-user.

Static sites can be deployed on the most basic of public file server -- even on a content-delivery network. The site performance is high, compared to many web frameworks like Drupal. Pages do not "render" or "build", rather the page files are delivered to the user's browser. The security risk is very low -- no risk of SQL injection attacks, for example.

Sounds simple, right? While the user-facing site may be "simple," the tools used to build your static site can be quite complicated. And that level of complexity varies quite a bit from one static site tool to another.

What are some examples?

Name a programming language or popular Javascript framework and you're likely to find a SSG that uses it.

Ruby has Jekyll. Python has Pelican. Rust has Zola. There's even bashblog that uses Bash.

As for Javascript ... there are too many to name. Some of the hot ones now are Gatsby and Next.JS which use React, and Vuepress which uses Vue.js.

Recently, I started learning Hugo and investigating whether it would pair well with Drupal. Stay tuned for more info on that experimentation.

It's important to note that historical memory can be short, and static site generators are not new. Not long ago, I had a job that involved migrating to Drupal from a system called Terminal 4. T4 was (and still is) a big content management platform that lived on the private enterprise network and used a database, but ultimately published HTML static files.

Compared to Drupal, T4 offered advantages and disadvantages. The positive is that the site admin doesn't have to worry about database performance, server load or security risks like SQL injection attacks. The negative is that now the content manager has to worry about how long before her content is published by a site admin, a process that she used to control.

I don't believe there is one right answer here. It strikes me that what's old is new again

Why use a static site generator?

I try to frame the pros and cons of static site generators from the lens of Drupal. There are many opinions on this.

Reasons to migrate to static site:

• as site admin, I can retire the old Drupal site instead of having to maintain updates, or at least put it on a private network.
• as a site designer, I don't have experience or enjoy working with Drupal's theme system; a static site tool is probably easier to work with.
• as a site architect, I would prefer hosting all the site files on a CDN and not a Drupal-friendly server that someone has to configure and manage.

Reasons to stick with Drupal:

• as a content editor, I don't want to lose the web-based text editor, media library, taxonomy management and all the other nice content management tools that Drupal provides.
• as a content manager, I need to have the ability to manage custom user permissions and roles, or content access.
• as a content producer, I am not interested in learning how to write in Markdown or some other format that doesn't look like the web-based editor I already know.

What about Hugo?

Hugo is the static site generator that I've been experimenting with of late. I began looking into it solely because it is written in Go, a language that I have been learning. It has not been easy!

Moving from one framework to another like this requires learning a new vocabulary, mapping your old paradigm to this new one. Sometimes it's an easy transition, like trying to learn Spanish if you speak French. Sometimes it's not. Drupal uses "content" and "content types," while Hugo uses "frontmatter" and "archetypes." When it comes to spoken languages, you can find a dictionary that translates one language to another. Good luck finding a translation of Drupal to Hugo!

Step 2: Hugo Export Module