< More Posts
Published 21 February 2020 at Yours, Kewbish. 1247 words. Subscribe via RSS.
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.
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.
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.
++ 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
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.
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!
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.
MLA: Ma, Emilie. "Hugo." Yours, Kewbish. n.p., 21 Feb. 2020. Web.
APA: Ma, E. (2020, February 21). Hugo [Web log post]. Retrieved from https://kewbi.sh/blog/posts/200221/
UBC citation style.
- Yours, Kewbish
< More Posts