r/gohugo | reddlx

Some tools for easier blogging with VS Code.

I've bounced in and out of Hugo for a few years but, since last fall, I've finally invested in making a workflow that works for me. Originally it was just a set of scripts for things like handling taxonomies, creating and publishing drafts automatically and a few other things. Lately it's been expanding on those scripts with new VS Code extensions for making image handling easier and better counting my words to publishing. Since March or so I've started publishing all this stuff in hopes it might help some other folks too. Here's what I've got:

First, my theme: https://github.com/ChrisWiegman/kana-hugo-theme

Next my OG scripts which I've published as an npm package: https://www.npmjs.com/package/@chriswiegman/hugo-tools

Then there's two VS Code extensions:

This one better handles word counts in content: https://marketplace.visualstudio.com/items?itemName=ChrisWiegman.cw-markdown-word-count

And this one let's me just drag and drop images into my content while the extension handles the rest: https://marketplace.visualstudio.com/items?itemName=ChrisWiegman.vscode-hugo-image-importer

Taken together, they're finally a way for me to make use of Hugo without wanting to go back to WordPress. Most of my career was spent in WP including some of the bigger plugins so escaping its gravity was harder for me than most. Here's to hoping these can make things a bit easier for y'all as well.

u/ChrisWiegman — 4 days ago

▲ 19 r/gohugo

I've been building Hugo sites for years, ranging from personal blogs to large-scale enterprise documentation portals. One thing I've learned is that it is easy to make a Hugo site fast, but it takes discipline to make it scalable and maintainable.

Here are three specific patterns I use to ensure projects don't turn into a "spaghetti code" nightmare as they grow.

1. Aggressive Caching with "Partial Caching"
Most developers know about partials, but many underutilize the caching mechanism available in Hugo.

If you have a partial that generates a navigation menu, a footer, or a related content section—and the output doesn't change based on the specific page context—there is no need to render it on every single page during the build process.

By utilizing cached partials, you can drastically reduce your build times.

2. The "Isolation" Pattern for CSS & JS
A common issue I see in theme development is loading a massive main JavaScript bundle on every page just to support one interactive component on the homepage. This kills your PageSpeed scores and bloats the site.

I enforce a strict "Page-Specific Asset" architecture. This means defining specific zones in the base layout where individual pages can inject their own scripts or styles.

This keeps the payload light and ensures clients get perfect Google PageSpeed scores without fighting "unused JavaScript" warnings. It ensures that a blog post doesn't load the heavy scripts required for the homepage slider.

3. Relational Content without the Database Overhead
Clients often ask for complex features like "Related Posts" or "Staff Authors" linked to articles. The naive approach is to loop through all pages to find matches, which is resource-heavy and slow.

The expert approach is using Hugo's built-in indexing and intersection logic. By configuring the site's "related content" indices properly, you can perform complex relational queries instantly without the need for an external database or plugins. It keeps the site static, secure, and incredibly fast.

The Takeaway
Hugo is powerful. Writing clean, modular templates isn't just about code aesthetics; it's about keeping build times low and client maintenance costs down.

Happy Building.

reddit.com

u/juntoamdin3000 — 9 days ago

▲ 3 r/gohugo+1 crossposts

I’m deciding how to handle the top navigation bar on my Hugo-based blog and would appreciate some input.

Right now, the menu hides when the user scrolls down, which gives more space for reading and keeps the content in focus. However, this behavior requires extra complexity. It involves tracking scroll efforts and using JavaScript for smooth show/hide (fade in/out), which adds some overhead.

The alternative is to keep the menu fixed at the top at all times, both on desktop and mobile. That simplifies the implementation but permanently takes up screen space, especially noticeable on smaller screens.

From your experience, what’s the better approach?

Keep the menu always visible (fixed)
Hide it on scroll to maximize reading space

Any insights, trade-offs, or best practices would be helpful.

If you want to see the current implementation in action, you can check it here: https://denshub.com/

u/RankLord — 9 days ago