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.
Not 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.
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.
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.
I worked in the Bay Area during the dot-com boom and large swathes of time were effectively 996. I was generally irritable, gained a bunch of weight (up to 220; am now 170), and eventually burned out. What was old is now new. Perhaps AI encourages 996'ing, but people will still burn out just the same.
I WiFi enabled my fridge because the thermostat broke. So now an ESP32 with a dallas temperature sensor and a relay take care of that. The code on the ESP32 is smart enough to keep working if there is no internet (wasn't always like this, until it had to), but it still sends the temperature to the server for logging and the server can send it configuration commands or control the relay directly, as it was initially.
It was a great way to keep the fridge alive, the thermostat was already a replacement and it never worked properly, so that sometimes things were frozen, sometimes barely cold. ~24 years old. A new one would be more efficient, but then I woudln't be able to log when I opened the fridge anymore (only with something battery powered and long transmit intervals).
This is awesome, great way to keep a fridge going! Temp sensor to ESP32, ESP32 monitors set point and calls for cool, output from ESP32 energizes relay coil which turns on the compressor?
> A new one would be more efficient, but then I woudln't be able to log when I opened the fridge anymore (only with something battery powered and long transmit intervals).
Also, how did you do this? Wiring to the door switch itself or a current switch around the fridge light conductor?
i also have questions. was the fridge "smart"-capable prior to the esp32 mods and you just replaced the factory controller with your esp32 stuff, or youre saying you wired in the appropriate circuitry to replace the pressure-controlling thermostat with your esp32 stuff?
it was not smart-capable. I was very lucky that the thermostat was in the fridge itself, above the compartments. There I removed the old analog control and had enough space to fit a USB power supply to the cables which were there connected to the now-removed analog control. I was lucky.
The sent data gets stored in InfluxDB. So with Grafana it allows me to see when I opened it, because the temperature rises immediately.
I took Spanish in high school and college, so had a rudimentary understanding of verb tenses and some vocabulary. Before I walked the Camino de Santiago el Norte (45+ days in Spain), I used Duolingo to brush up on my Spanish.
It helped my reading most, my speaking a fair amount and my listening/conversation the least. I was able to ask questions, but was often flummoxed at any reply that wasn't the most basic.
I grew to hate the gamification, but was addicted to my "streak' also ... using math lessons when I didn't feel like doing a Spanish lesson. The so-called "leagues" were kind of useless since the same people weren't in the league from week to week. Any friendly competitiveness to "learn more" was lost when randomly assigned to a different group each week.
I finally abandoned the app this spring.
I'm trying Babbel now since I'm going back to Spain for a month and Patagonia next year.
I don't understand people who say this. I completely ignore the gamification. If I don't feel like doing it one day, I don't do it. I don't even know what the leagues are, despite seeing people talk about them. I never look at any score or badge that they provide.
You have to click through a lot of it. If I open it and do a lesson, it will demand I commit to a streak (if I haven't done it in a while), show me the new 1-day streak, show me about streak freezes, see how much XP I got, see what quests I made progress on, see that I did not get promoted in the leagues, see my new league placement, and probably a dozen other things that aren't language learning. I don't care about this stuff, but I'm forced to interact with it to use their app.
Duolingo makes it hard to ignore - the whole app is gamified. It's like ignoring water while swimming in the ocean. Yes, you can turn off notifications, but sometimes they were helpful.
I think gamification triggers some innate feature of our brain, just like TikTok or Reels or mobile games, etc. It is designed to be hard to ignore.
This may be part of it. I refuse to use the app. I use the website only.
It sends me daily reminder emails, which I use as a reminder to do it if I have a chance, otherwise I ignore them. It flashes up a bunch of crap after I complete a lesson that I just mindlessly click through. Which could be the league stuff you mention but I ignore it.
> just like TikTok or Reels or mobile games
Fair, I have the same question about those. It boggles my mind that people fall for the gamification of those too. Or even back in the day stuff like badges in StackOverflow. If one doesn't care, one doesn't care.
Then you missed the point of my post. That money never did. It went back into the hands of the investors, the investors that are now putting money into genAI.
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.
reply