Evaluating the Choices

Website Development

Did you ever have to make up your mind…

It seems that whenever one sets off to start a new project, the first thing one has to do is survey the range of tools and workflows that are currently available in order to make sure that one does not reinvent the wheel or go down a path that turns out to be a dead end. The project to determine how to implement the current generation of Ki2.com is no different. In the early days of IEEE 802.11 the group spent a couple of years working to codify the “Functional Requirements” for the new standard. I have found that this is a practice worth supporting. A good place to start with this first step is to identify the items that “we know that we know”.

Towards this end, starting out, I knew that I was going to host the sites on Microsoft Azure. This knowledge did not come from some evaluation of the competing platforms, but rather from a history of familiarity with this platform and an overall level of satisfaction with that history.

Knowing this I first spun up an instance Wordpress. I had at first thought that this might be a simple way to get the project done without a significant learning curve. I very quickly found out that the fact that Wordpress requires an instance of a database server was going to cause there to be a non-trivial floor to the monthly cost of running the site.

Given the dynamic, database driven nature of the Wordpress solution I was also concerned about security and reviewed the CISA Alert Database to determine how much of an issue security might be on an ongoing basis. This led me to a second “Known Known” and that was that a Static Web Solution would have superior characteristics from security and cost perspective.

So the “Known Knowns” were:

  • The sites will be hosted on Microsoft Azure
  • The sites will be implemented as Static Web Pages

The next step was to research what tools Azure had to support this and what packages were candidates for the underlying framework. A brief introduction to Azure Static Web Apps indicated that there were three initial frameworks to investigate and the were Gatsby, Hugo, and VuePress. I also found that Jekyll was a candidate.

As is the case in any evaluation of competing solutions the answer is dependent on where the evaluator is coming from and what their previous knowledge base looks like. Someone who has spent years writing javascript code might make one choice, someone else who is fluent in Ruby another. For me, I have written more code in assembler languages, Fortran, Visual Basic, Mathematica and Python than any of the above so other than the similarity of Hugo templates to some assembler macro capabilities none of these pointed me in any particular direction. I reviewed a variety of sites such as Static Site Generators Overview: Gatsby vs. Hugo vs. Jekyll and came to the conclusion that Hugo was right for me. In a nutshell the factors that drove this choice were:

  • Speed and Efficency
  • Lack of dependencies (you can upgrade Hugo on a system by replacing one executable)
  • Content File structure map sets site structure.
  • Robust but simple templating features
  • Research into the origins of the Go language appealed to the historian in me
  • Simplicity of integration with GitHub source control and ease of deployment

Having made this decision, Tutorial: Publish a Hugo site to Azure Static Web Apps provides a good “Trail” for getting the application implemented both on your local system and on an Azure Instance. I found that when deploying the Theme for my site the directions at Install and Use Themes work better for my use case than the suggestion in Item 7 under the Create a Hugo App section in the Microsoft tutorial that suggests the you execute:

git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke
echo 'theme = "ananke"' >> config.toml

I would rather just load the theme on my local machine and take control of the future updates of that theme as part of my normal commit process rather than add an additional layer of complexity and possible confusion associated with the use of submodules.

In my case, Visual Studio Code is my editor of choice and with this I am able to generate content in Markdown form and handle the interactions with the GitHub source code repository without the overhead and complexity of larger integrated development environment.

So as they say in horse racing “They are all in the gate”, the first round of choices are made and implemented. The next post will be about the choice of theme and the process of generating the content so that it is organized well within the theme.

Not sure if some of the younger folks are familiar with the title reference of this post … afterall it’s the 60’s The Lovin' Spoonful