Hugo vs Quarto Blog
Why I switched to Hugo hosted on Netlify
Contents
This post is a reply to my three-year-old post on my previous attempt to create a personal site, in which I explained why I chose R Distill (now called Quarto blog) + Firebase Hosting. I’ll outline what has changed and what hasn’t since then, which made me land on Hugo + Netlify. In the next post I’ll describe my “blogging stack”, which comprise all the tools I use from ideation to published blog post. In summary, I am happy I made the switch to Hugo and my current blogging stack works well.
What requirements are the same?
- Markdown. Having become used to writing documentation and personal notes in Markdown, it is the natural pick for a markup language for a technical blog. Simply plain text files with standard Markdown syntax, which allows for writing and editing in multiple editors. Markdown also allows for HTML tags, making the format highly customizable when there is a need for that. I use the LanguageTool Obsidian plugin for grammar and spell checking, which works pretty well. What do I miss from a WYSIWYG editor like Google Docs or Microsoft Word? Not much, but there are times I wish I could select text in my Markdown document and add a comment to it. This, adding annotations to my writing, is convenient. I’ve started to use Markdown’s footnote notation for this, i.e. adding a footnote (syntax:
[^foo]
) close to the relevant text and then write the footnote content somewhere nearby (syntax:[^foo]: this is the comment in the footnote.
). It gets me close enough. - Static website. The rendered site should only be composed of HTML5 components. A static website hosted on a CDN is cheap (free in my case, with the generous free tier offered by Netlify) and can scale to high traffic if that occurs. Both Quarto blog and Hugo are static website generators, just like other popular alternatives like Jekyll and Gatsby. Why not an online publishing platform like medium.com or dev.to? I am not that fond of medium.com to be honest, with its frequently paywalled content. dev.to is better in that regard, but I guess the main motivation for picking Hugo instead is the combination of full control over the UI and hosting. And, the most enticing prospect of a publishing platform – larger audience reach – does not matter to me. I write mainly for myself.
- Should work well on small screens. I mostly read newsletters and blogposts on my phone, and the reading experience on small screens varies greatly. It is important to me that all my posts should be easy and comfortable to consume on both small and large screens. It might require extra effort to get things right for small screens, but that time investment feels right to me.
- Minimal maintenance and “publish post overhead”. I am fine with using a dozen hours or so to set up and configure my blog the way I want it. But once I am happy with it, there should be minimal overhead to the process of writing, deploying and getting things to look and behave well. When I feel like writing about something, I should be able to sit down and spend 99% of my time focused on writing; not struggle with blog deployment issues or frustrating CSS1. It took time to find and tweak a Hugo theme I liked and that matched most of my criteria. I landed on the DoIt theme, which had an extensive set of built-in capabilities. I made some modifications to the theme, like making the Posts page contain more metadata (I found the stock Posts page to be too minimal) and the dark theme more contrasty2. It only takes a few seconds from push to GitHub to having a newly deployed site (mainly due to Go being so fast). Currently, I am pleased with how things look and behave, allowing me to easily get into Zen focused writing time 🤓.
What is different now?
- I have switched from Data Scientist to Data Engineer. I am pretty agnostic about my job title – my goal is to be a Data *Anything*3 – but after switching to work more on the engineering side of things in my day-to-day work, I have less need for easily making “insights posts”. By insights posts I mean blog posts that benefits from being written in a Jupyter/Quarto Notebook, which enable authors to combine text, code, data, and visualizations into a coherent, reproducible narrative. It is pretty nice, to be honest, but it introduces overhead when I don’t need these things. Going forward, I think most blog posts will be mainly plain Markdown files with no need for rendering Python/R to produce final HTML output. A Quarto blog uses Notebooks (file extensions
ipynb
orqmd
) as its main component for posts, which now becomes overhead for my writing needs. On the other hand, if I were to write an “insights post” one day, I could still write it in a Notebook and then export the rendered output to Markdown. One extra step, but that’s fine. Plain Markdown, yes please! - I prefer full control over layout, UI and publishing. I think I could be 95 percent happy with an off-the-shelf personal site like a Quarto blog, but there would always be some things that I’d wish I could tweak. Hugo feels like the right choice to me, as it allows me to pick a theme giving me the 95 percent but also the possibility to easily tweak and fix the few things that isn’t exactly how I want it.
- I prefer Go over R. This is not to bash
R
, it is a great programming language for data analysis and statistics, which I’ve spent thousands of hours with. However, in my day-to-day work, I don’t useR
any longer. Analytics and statistics needs are covered by Python and SQL (mainly because Python is closer to our production environment, keeping this gap short is beneficial). Backend, cloud, and data engineering tasks are written in Python, Go or a higher abstraction like Benthos or Miller. When not usingR
any longer, there is less reason to pick a Quarto blog.
See the next post for my current workflow and the tools I use for getting things published to this site.