7 ms·
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 answ
by dougdonohoe 6mo ago
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.
- Terretta 6mo agoNot judging you, but from the response you pasted here, it could be either your Claude or your prompt wants Claude to be supportive. In a new thread, make sure it can read your project into context, then have it explain what Hugo is (to add more context), then ask something like: Given your understanding of Hugo and your analysis of this project, why would this project have been better return-on-engineering as a photo gallery themed Hugo blog with user uploads instead? In general you'll get a less sycophantic answer, and of course, with it playing devil's advocate, you end up with a stronger argument. // I like yours, and think I'd be more likely to choose yours than Hugo for this.
- dougdonohoe 6mo agoI 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.
- andrei_says_ 6mo agoTurns out for a photo gallery json is just a bit tiny-er than html. And static html is so much simpler. With proper links just working with the browsers built-in nav.