New Site
Drew LeskeI’ve rebuilt the previous team website using Hugo. Wordpress is fine and all and it’s the official CMS platform at UVic with industrial-level support, but while it’s great for most people, I found it did not fit into my preferred workflow, and I was not alone in that in the team.
The main thing probably is the editor. It’s fine and good but it’s WYSIWYG and right in the browser. As it should be, for what it is! But in our development we write a lot of Markdown, and we include a lot of code or terminal snippets. A Markdown editor wasn’t easily available and including all the code snippets was fairly tedious: when you’re describing a list of commands to run on a VM, for example, there are going to be a lot of text blocks that need to be selected and formatted as code or preformatted or whatever. With Markdown, it’s three backticks in a row and then enter. More typey, less mousey, that’s my motto.
The other benefit is publishing the website becomes the same as publishing our
code. For now it’s make publish, and down the road, when I get a chance,
it’ll be automated via GitLab CI. Because, of course, everything’s now in
Git. Just like all of our code. Sweet, sweet consistency.
So how’s that go then
Hugo is a static site generator which means its output is HTML and other static files. These files are then transferred to a webserver where they can be made available to visitors, but there is no server-side script engine parsing a website template and evaluating that against an environment of client and server contexts: it’s just basic web page serving like was pretty neat in 1995. Coders might see it as a compiled website versus an interpreted one.
You could think of it as a basic Wordpress site that you do your normal thing with to add and edit pages, but when you’re ready you take a snapshot of the whole site and put that on a webserver. That’s a terrible analogy, and also, recreating the functionality of some Wordpress sites and the plugins they rely on in Hugo could be a significant undertaking using client-side Java, third-party microservices or server extensions.
How does it work though
We describe our projects, write log entries or documentation as text files whose names and locations define their relationship to the rest of the site. These files are formatted with Markdown and begin with front matter which describe the content and its purpose.
Hugo supports theming and a specific theme, Teaming (I’m not at all settled on the name), to suit the specific needs of this kind of site.
Everything’s in a Git repository (the theme is invoked as a submodule) and when members create a new blog post or other content, it’s like any other source code: create, update and commit your code, and submit a merge request. It’s merged and then published.
Without server-side scripting providing something like a web store or interactive content requires Javascript to be executed by the client and some third-party service. Fortunately that’s not what this site needs.