dougdonohoe

I had asked about Hugo in the first prompt, and it told me what it was, and then my prompt was:

"Huh, could you build my functionality using Hugo [link to repo]? I mean I'm using dynamic JS features"

And the above was the response. I didn't put more than 10 seconds thought into it. The commenter claimed I could build the site with less code with a tool I had never heard of and I was curious if I had missed something.

I've never heard of Hugo until I saw subpixel's comment. I was curious and asked Claude if I could have built my site using it. Claude's response:

Short answer: technically yes, but it would be a worse fit and require real workarounds.

Here's why your project strains Hugo's model:

The core mismatch — client-side JSON fetching. Your architecture has photogen generate static JSON index files, and then the SvelteKit frontend fetches those at runtime in the browser. This is intentional — it means the HTML shell is pre-built and tiny, and photo data loads dynamically. Hugo assumes it will have all content at build time and bake it into HTML. Your approach of loading JSON client-side is fundamentally at odds with Hugo's philosophy.

PhotoSwipe lightbox + swipe gestures. This is a JavaScript-heavy component for the full-screen photo viewer with swipe, keyboard navigation, and captions. Hugo doesn't prevent you from using JS, but you'd be bolting it on rather than having it as a first-class part of your component model. Managing that in Svelte components vs. Hugo templates is a real quality-of-life difference.

Shareable photo permalinks (e.g. /albums/patagonia/5) that resolve client-side — this kind of dynamic routing within a static shell is SvelteKit's bread and butter. In Hugo you'd have to either pre-generate a page per photo (slow builds, lots of files) or do ugly JS hacks.

Dark/light theme toggle, justified grid layout, OpenGraph tags — these are all doable in Hugo, but you'd essentially be writing a SvelteKit app inside Hugo's templating language, which is less ergonomic.

The bottom line: Hugo shines when your content is known at build time and the interactivity needs are minimal. Your site has a static shell but runtime-dynamic data loading and a rich JS-driven UI. That's exactly the gap SvelteKit fills. Hugo looks applicable at a glance — but once you look at what the site actually does, SvelteKit is the right call.

Correct - if the resized image is already there it is skippped (this can be overwritten with -force flag).

Thanks, appreciate it. I'll checkout thumbsup too.

No real challenges. I made the Go `photogen` tool run in parallel using goroutines (e.g., 3-6 depending on your CPU). It's pretty fast at churning through hundreds of photos.

My question to my team was always "Is it done, or done-done?". Which is another way to say this, I suppose.