Skip to main content
  1. Posts/

Migrating from Jekyll to Hugo Part 1: Why I Made the Switch

Chris Ayers
Author
Chris Ayers
I am a father, nerd, gamer, and speaker.
Hugo Logo

After years of running this blog on Jekyll, I finally made the switch to Hugo. Here’s why.

Why I Made the Switch
#

Static site generators have evolved a lot since Jekyll first popularized the idea of building blogs from Markdown. Jekyll served me well for a long time, but as my site grew and my workflow matured, a few pain points became impossible to ignore:

  • Build times: As my site grew, Jekyll builds slowed to a crawl. Waiting 30+ seconds for a rebuild made local development feel sluggish.
  • Ruby dependencies: Managing Ruby versions, gems, and Bundler across machines and CI environments was a recurring frustration.
  • Theme flexibility: I wanted a more modern design system, better dark mode support, and a theme ecosystem that felt alive.

Hugo promised faster builds, a single binary with no external dependencies, and a more modern templating system. Once I started experimenting, the difference was immediate.

Why Hugo Is a Better Fit
#

Fast builds
#

Hugo compiles entire sites in milliseconds, and the dev server hot reload feels instant. That alone dramatically improves the writing and editing experience.

No dependency headaches
#

Hugo is just one binary. No Ruby, no Bundler, no gem conflicts, no version juggling. It works the same on every machine and every CI pipeline.

A more powerful templating system
#

Hugo’s Go-based templating is far more flexible than Liquid. It supports:

  • Rich built-in functions
  • Complex content structures
  • Custom taxonomies
  • Shortcodes
  • Image processing
  • Multilingual content

Many things that require plugins in Jekyll are built directly into Hugo.

A modern ecosystem
#

Hugo’s theme community is active, innovative, and built around modern tooling. This is where Blowfish really shines.

Choosing a Theme
#

I settled on the Blowfish theme for several reasons. Honestly, it is one of the best examples of what Hugo makes possible.

Blowfish illustration

Clean, modern design
#

Blowfish looks great out of the box, with thoughtful typography, spacing, and layout options.

Dark mode support
#

Automatic dark and light mode, user-selectable themes, and customizable color palettes are all built in.

Feature-rich components
#

Blowfish includes components like:

  • Callouts
  • Cards
  • Tabs
  • Accordions
  • Grids
  • Footnotes
  • Copy-to-clipboard code blocks

These let you build richer content without custom HTML.

Built-in image optimization
#

Thanks to Hugo’s image pipeline, Blowfish can automatically resize, crop, optimize, lazy-load, and serve responsive images. This is something Jekyll cannot match without external tooling.

Taxonomies and structure
#

Categories, tags, sections, menus, and breadcrumbs work cleanly and consistently.

Active development and documentation
#

Blowfish is well maintained, well documented, and constantly improving.

Tailwind CSS for customization
#

If you want to tweak the design, Tailwind makes it straightforward.

Jekyll vs. Hugo (with Blowfish): A Practical Comparison
#

Feature / AreaJekyllHugo (with Blowfish)
Build SpeedSlow on larger sites; rebuilds often 20-60 secondsExtremely fast; rebuilds typically under 1 second
DependenciesRequires Ruby, Bundler, gems, and version managementSingle binary, no external dependencies
Templating SystemLiquid (simple but limited)Go templates (powerful, flexible, feature-rich)
Image ProcessingNot built in; requires external tools or pluginsNative image pipeline: resize, crop, optimize, responsive images
Theme EcosystemMany themes, but many feel dated or unmaintainedModern themes with active development; Blowfish is a standout
Dark Mode SupportTheme-dependent; often limitedBuilt-in automatic dark/light mode plus user theme switching
Content ComponentsLimited; requires plugins or custom HTMLBlowfish includes cards, callouts, tabs, accordions, grids, and more
SearchRequires external JS libraries or pluginsBlowfish includes fast, built-in client-side search
Multilingual SupportPlugin-based, inconsistentFirst-class multilingual support built into Hugo
TaxonomiesBasic categories/tagsFlexible taxonomies, sections, menus, breadcrumbs
Asset PipelineBasic; often requires pluginsBuilt-in minification, fingerprinting, and processing
CustomizationVaries by theme; often requires manual CSSBlowfish uses Tailwind for easy, modern customization
DocumentationGood but plugin-heavyExcellent docs; Blowfish has strong theme documentation
Local DevelopmentSlower reloads; can feel laggyInstant hot reload; smooth editing experience
CI/CDSlower builds; Ruby setup requiredFast builds; no setup beyond Hugo binary
Learning CurveEasy to start, harder to extendEasy to start, powerful as you grow

Results
#

After migrating, a few wins stood out:

  • Build time: Dropped from 30+ seconds to under 1 second
  • No dependencies: Just the Hugo binary, nothing else
  • Better DX: Hot reload is nearly instant
  • Modern design: Blowfish looks great on all devices
  • More flexibility: Shortcodes, components, and image processing make content creation easier

Overall, the site feels faster, cleaner, and more maintainable.

What’s Next
#

In Part 2, I’ll cover the actual migration process:

  • Converting posts
  • Fixing front matter
  • Replacing Jekyll shortcodes
  • Handling images and static assets
  • Structuring content for Hugo’s taxonomy system

If you’re considering making the switch yourself, the migration is easier than you might think.

Resources
#

Related

Customizing the Jekyll Theme

I haven’t done a lot with jekyll in the past, but I’m a big fan of Markdown everything. For me that usually means I’m taking notes in Markdown Obsidian, doing diagrams in mermaid in Azure DevOps or https://mermaid.live/. I’ve even started turning my talk slides into Markdown with a tool called MARP. Understanding when I use standard Markdown or some sort of templating language (jekyll uses Liquid) has been fun. I’ll do something in HTML or Markdown, then find out that Jekyll or my theme already has helpers to render that (like gists, videos, and figures). Sometimes rendering more advanced things takes a little tweaking of Jekyll and the theme.

Migrating from WordPress to GitHub Pages

I’ve been hosting on WordPress for a while. I wanted something that worked pretty well and was easy to work with. I picked a decent theme, added some plugins, pointed my domains and was up and running. I would work on blogs in Markdown, and then paste the txt into a Markdown. I could upload a few images and move them around in a wysiwyg. Lately, I’ve been doing a lot more in Markdown. All my conference talks were in PowerPoint but I’ve started switching over to Markdown slides using MARP. I should probably do a post on MARP sometime (I did :-) ). I wanted to reduce my overhead of WordPress Hosting and get back into more direct styling and coding of my theme. I decided to switch my hosting to Jekyll on GitHub Pages.

Multiple Domains on GitHub Pages

Something I found out after moving from WordPress to GitHub Pages is that out of the box you can only host a single domain for a repository with GitHub Pages. This is a problem for me because I have a number of domains I was hosting at WordPress that I wanted to point at my GitHub Pages. Official Docs and the limitation # So officially, GitHub pages doesn’t support multiple domains. The docs here https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages#custom-domain-names-that-are-unsupported state:

Embedding Draw.io Diagrams in VSCode

·942 words·5 mins
If you’re like me, you love discovering new ways to boost your productivity and workflows. One of my favorite tools is Draw.io. I’ve used the desktop tool and the site, but I found a new integration that has significantly elevated my VSCode experience: the Draw.io Integration extension.