Hugo.

Introduction

Recently, I began a new blog, hosted on GitHub Pages over here. In the past, I’ve tried (and eventually failed) to set up a devlog section on my site, and one of the main pain points was the repetitiveness of creating and pushing content. I had a template with very bare-bones HTML and CSS that I copied and pasted my work into, but this was annoying to constantly try to move my plaintext into rich HTML content. I ended up destroying the repo because it just became a burden to write for and maintain content for, which turned me off blogging or creating any internet content, basically, for about a year. However, with my recent GCI win, I felt that I needed to step up my digital presence and start devlogging for real.

Looking for a SSG

Firmly entrenched in the idea of starting a blog and publicly learning, I began searching for some sort of generation tool.

Briefly, I considered biting the bullet and starting a Wordpress site. However, after a couple seconds of reconsidering (goddammit Kewbish, do you really want to do this?), I immediately discarded the idea. Having worked with Wordpress (and Weebly, if anyone cares), I knew how boring creating a site there would be, especially without the ability to fine-tune files and configure my site exactly as I liked it. As well, it would add a lot of bloat and annoyance to initial setup. Besides, then I’d have to deal with another subdomain - (shut up, I’ll get a domain soon).

Platforms like Medium and Dev.to allow an easy startup, but it wouldn’t allow me to change much styling, and I’d either get stuck behind a paywall somewhere (Medium) or be limited quite a bit to a developer audience (Dev.to). These platforms would give me a great starting readerbase and starting point, though I guess my inner demon-angel wouldn’t let me do anything less than sink a week into learning something new.

The logical next step for me was a SSG (Static Site Generator). I’d heard of Jekyll, and its integration with GitHub Pages made it attractive, but the startup of having to install Ruby, a language I’d not used (and frankly, don’t plan on using) made me reluctant.

Gatsby had a great community, and its clear documentation brought it up as a good choice. However, despite my experience with web development, I’ve chosen to steer relatively far away from JS-based tools (and haven’t touched Node at all yet. One of the items on my ever-growing to-do list.) Therefore, I felt I should keep looking.

Choosing Hugo

Enter Hugo. Hugo seemed like an amazing compromise: easy startup (though I’d have to handcode a theme) and relatively low bloatage. (As well, the community around the tool and its frequent maintenance made it extremely attractive.)

Taken from Sebastien Duc.
With Hugo in hand, I set up to create the blog of my dreams.

Site Setup

I’m familiar with Markdown, so writing for Hugo’s Markdown-based generator wasn’t a challenge. In fact, the most difficult part of the whole setup was probably theme development.

Theme Development - The prideful human I am, I couldn’t just use a premade theme (of which there are plenty, if you were wondering). (Oh, the horror.)

I started off then with a basic theme, and created the Markdown first. Then, I began styling my site with some basic CSS. It’s still pretty bare-bones, but I feel like it’s good enough for my basic purposes.

I’m still pretty new to Go’s Templating tools, but the Hugo documentation more-or-less described most of the variables I needed, as well as linking to forum posts detailing some of the features I implemented. Again, the community is amazing, and super active.

Deployment - ++ to Hugo for providing a commit script. I have a recreation here (💀 no longer exists) for their gh-pages deployment solution, for all y’all Windows folks. Overall, this part’s relatively easy to follow, as long as you’re Terminal / Command Prompt savvy.

I would have liked some sort of inbuilt hugo command for this, but porting the bash script to batch wasn’t difficult, and generally ended up fine. I definitely recommend familiarizing yourself with worktree before attempting a GitHub Pages deploy.

Using a SSG

Having had both a handcoded blog and now this SSG site, I definitely prefer the workflow of the SSG. The ability to create custom themes brings the aesthetics to the level of a handcoded website, adding the DRY principle. Simply creating and formatting a MD file is a lot easier to manage than copy-pasting a bunch of components from hand-made templates. Besides, Hugo allows partials and other inbuilt templates-inside-templates, and everything is customizable.

The following are some common cons, and what I have to say. - SSGs are difficult to learn. False, actually. If you’ve some Markdown knowledge, and basic experience with HTMl / CSS (what you’d need for a handcoded approach anyway), you can learn Hugo. Hugo, in fact, is packaged into a single binary, and doesn’t require other installs, unlike some other SSGs.
- Every time I deploy, I have to rebuild. This is true, but I find the Hugo workflow better than the handcoded approach, especially with automation scripts.
- SSGs work with files, instead of a database. This is a minor pain point, and means that as my blog grows, I’ll need to manage my files well, instead of just tucking them into a database somewhere. However, I argue that this leads you to think about file structure design before the issues build up, and construct a scalable system in the beginning.
- No one’s ever heard of SSGs besides technical people. Wordpress, for sure, is a major player in the non-handcoded-site industry, but I feel the powers of open source and community outweigh the market strategy. Anyways, if I can build the same thing, there’s no point in switching if all else equal.
- Team and user management is nonexistent. In the traditional sense, yes, there can’t be admins and writers and whatevers as you do with Wordpress or Weebly. However, hosting on a platform like GitHub Pages opens up even more possibilities, giving you the tools to collaborate even more.

Conclusion

My migration process (or initialization process) was relatively painless, and I prefer the workflow to that of a handcoded experience. Hugo provides a great, open source framework for blogging and deployment to GitHub Pages (major ++), which is what I use anyway.

Stop by and check the blog out, and if there are any errors anywhere, open an issue and let me know!

Currently

I’ve just finished GCI, and have the VDSF soon, so I’m speedrunning my project and polishing it up.

Otherwise, I’m in a bit of a quandary on projects, but I think I’m going to continue Opus, a book tracking system I’ll build based on what I need personally. For that project, I’ll be using Kivy to create an iOS app (don’t worry, it’ll be on Android too, but I won’t release it on the Play Store).

Recently, I’ve been thinking more about what I’d like to specialize in - web development, Python, some combination of the two, or delve deeper into lower-level languages and technologies. For now, I’ll continue with what I’m familiar with, which happens to be web technologies, but I’m seriously considering learning C++ or perhaps some sort of machine learning project. Tensorflow’s been on my list for ages as well.
Just some thoughts.