In the Beginning, There Was WordPress
A beginning is the time for taking the most delicate care that the balances are correct.
- Frank Herbert, Dune
The previous blog used WordPress. Some of you are rolling your eyes. I don’t blame you! Hear me out though! My reasoning for picking WordPress was ease-of-use, something I could get up and running quickly. I am not a front-end engineer. I did not want to spend my time learning front-end things. So, yeah, WordPress.
I have a lot of patience, but my patience is finite. I used WordPress for over a year. Posting became… not fun. Posting became a chore. Posting was a slow process. Posting, the back-end portion, was painfully slow. A few weeks ago, I started looking for an alternative.
The Requirements
The tech chosen for the new blog needed to meet some key requirements.
-
Easy CMS - Posting and modifying content should be easy, not a chore.
-
Low Maintenance - I miss the days of “set it and forget it”. This would be nice.
-
Speed - Google’s PageSpeed Insights gave the old blog a Performance score of 33. The First Contentful Paint took 9.3 seconds. Yikes, gross.
The Frog Prince Jekyll
I ran across a post on HackerNews where SSGs (Static Site Generators) were being discussed. SSGs are not new. Specifically, SSGs were not a new, shiny, cool thing, to me, so I glossed over that option.
After some research, I started with Eleventy. Then Gatsby. Then Hugo. This blog came very close to being built with Hugo. I learned a lot experimenting trying and failing. Tears, coffee and busted keys.
At the tail end of a Hugo marathon, I remember looking at my screen, eyes glazed over and thinking, “This is too much. Too much front-end work. I am doing something wrong.” Going down a rabbit hole is fine. If you find yourself saying, “Oh, dear. I do wish I hadn’t cried so much” or “It would be so nice if something made sense for a change” then you have gone too far.
I decided to regroup and go hands-off for a day and do more research. I ran across a video by Techno Tim. In the video, he went from start-to-finish in setting up a site based on Jekyll. I liked what he had done and was able to replicate it.
Azure, Jekyll & GitHub
With the prototype meeting all the requirements, the last thing was finding a hosting solution.
Hosting was something I had been thinking about. During my research I had run across some stuff on Azure Static Web Apps. Gatsby and Hugo are one of the Build Presets offered when creating an Azure Static Web App. Jekyll was not. One of the things I am currently studying is Azure so this seemed like the perfect opportunity to make the new Jekyll site work as an Azure Static Web App.
I used a Custom Build Preset for Jekyll when creating the Azure Static Web App. Figuring out Azure, GitHub, GitHub Action Runs, VSCode, etc. was much easier than my week working with Eleventy/Gatsby/Hugo, Node, JS, etc. The final process for managing the site and posting also met my requirements.
Conclusion
I am not a master of Azure Static Web Apps, GitHub or Jekyll. There is probably more room for improvement in my current process. That will be easy to recognize over time. In the meantime, the process for modifying the site and creating posts looks something like this:
- Add/Change site in VSCode
- Commit via VSCode (was using Git Bash for all things Git)
- Monitor/Verify GitHub Action Run
- Confirm changes on Live site
A future post will go over (re)creating the Jekyll site as an Azure Static Web App. This will be documentation for me and hopefully help someone else out there. For now, I am very pleased with the result. BONUS: Forgot to mention that using a Azure Static Web App isfree. Hosting costs reduced by 100%.