I created this site for two reasons:

I built version one of the site using Svelte and Sapper. I had worked on a number of sites (four, I think) using React and Gatsby. The whole node.js ecosystem left a bad taste in my mouth. It was like trying to build a house of cards in the shifting sands of a river delta. Svelte, on the other hand, was a breath of fresh air.

Soon after, Sapper was deprecated. Eventually, Sapper was replaced by SvelteKit. My plan was to migrate and modernize using SvelteKit. After much delay, I finally got around to working on version two. As I was preparing, I ran into an issue. Markdown. With Sapper, there were two choices for markdown processor: markdown-it and remark. I evaluated them both and chose the superior markdown-it.

Well, guess what. With SvelteKit, the only choice is remark. I played around with it and found it as bad as I remember. That was a show stopper.

I had a recent project where I needed to quickly port a site off of WordPress. Having worked with Hugo in the past, I used it as the static site generator. Doing this project renewed my interest in Hugo.

Could I use Hugo? I checked and Hugo uses Goldmark as its markdown processor. I found that Goldmark does just about everything I wanted. That settled it.

Under the hood

I built the site using the Hugo static site generator. A static site generator means that all of the processing is done at build time and only static HTML, CSS, and JavaScript files are sent to the web server. This gets you more speed, more security, and less complexity. Unlike WordPress, there is no database needed on the web server.

The pages are written in Markdown. Along with Hugo shortcodes, I can get pretty much everything I need. And if I can’t, there is always good hold HTML. I am using VS Code as my editor. I would still be using the Forestry CMS, but, alas and alack, it is no more.

Edits to the site are committed to my GitHub repository. The images are hosted on Cloudinary. GitHub is just a repo, while Cloudinary is also a content delivery network for the images.

When changes are pushed to GitHub, Netlify is notified. Netlify pulls the changes and runs the build command to create the static site. If the build is successful, Netlify distributes the site to its content delivery network. Thus, I do not need to run a web server — Netlify handles that for me.

Diagram of the version one site’s Jamstack

The site consists of markdown, Svelte, Sass, HTML, and JavaScript files built on the Sapper framework that are processed into HTML, CSS, and javascript and then distributed to a global CDN.

Forestry to GitHub and Cloudinary, GitHub to Netlify, Netlify and Cloudinary to the world

Overview of the edit, publish, serve process.

[Note: I will add the version two site diagram once I find and edit the original.]

Design

I have always maintained that designers and programmers are at opposite ends of a spectrum. No one has ever been able to prove me wrong. Though, I did work with one designer who also programmed. He was it: the magical unicorn that every job listing is looking for — designer and programmer. At least it seemed like it until I had to modify some of his code. OMFG, no, just no, no, no… He is not a programmer; rather, a designer who knows how to write a little code, big difference.

What is the point of my rambling? I am a programmer who did the design for this site. I know that it isn’t great. I just try to keep it from being awful.

The CSS for this site was originally written in SCSS. CSS has come a long way since then. I no longer feel the need for SCSS. Furthermore, we now have CSS cascade layers. This obviates all of those utility-first frameworks, like Tailwind. We can now use the full cascade as it was meant to be used.

Credits

I have to thank Luis Sanz for my avatar. He drew me as a character in a comic strip he wrote about life in the office. He said that I always gave him the best material. I also have to thank Virginia Odien for converting my avatar to SVG. My talents end before the art line.