Use right tools! don't be a die hard fan of any language.
However, I used many tech stacks including Hexo navy theme, Docusaurus, Docsy but ended up creating my own setup with Hugo. If you can see, in the project it's more or html/css that can be used with any builder.
I guess I'm of the wrong mindset that when trying to teach a language, it helps to do all the things in said language, because then you've got lots of fodder to write about and explain other people's code, pointing at your own use case as examples.
As I said, I'm clearly in the weird minority on this one and should have kept my damn trap shut. We are all free to make our own choices.
I suppose too I was coloured by my hatred of Hugo. :)
I was updating section by section from time to time. No lies! keeping a Rust tutorial up to date is very tough. Plus, you end up repeating what you already know. It is even tougher, when you have to write code in another language for work.
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.
Ex. Content can be in Git repo. Site can be build via static site generators + automated via CI update site when add new content to Git repo. We only need good blog theme, photo albums theme and profile theme to replace FB, Linkedin even TikTok. Publishers have full control on their own data.
I understand these points. As someone who truly love open source, we can see open source projects are becoming just a free training materials for AI. After training LLMs using open-source projects AI can build far superior software one day and that software may be not free, not able to replace by any non-AI software project. We all know that day is not far and that period of time all open-source software might consider legacy as no individual contributor able to implement stuff the speed of AI. What you are protecting is not only a legacy system we build decade old requirements and also the death of the purpose of why people build free software.
What we have to focus is why we created free software, not word by word terms that not fulfill the requirement at this and future time period.
You can't say you love opensource and be mad that users are using the freedom you granted.
OpenSource projects are not becoming free training material for AI, AI companies are using a freedom OpenSource projects granted.
The claim that AI can build far superior software is dubious and I don't believe it one second. And even if it were true, that does not change anything.
With or without AI, permissive licenses (MIT, BSD, ISC, ...) always allowed the code to be used and redistributed in non opensource software. If you don't want that, use the GPL or a derive. If you don't believe that the GPL would be enforceable on the derivative works produced by AI, don't release your code as opensource.
OpenSource is essentially an ideology, that software should be free of use, and transparent, and freely shareable, without restriction. If you don't buy into that ideology, it's fine, but don't claim to love OpenSource when you don't. Just like a person who eats fish should not claim to be vegan.
AI will not be the end of OpenSource, firstly because it's a dead-end technology, it has already peaked years ago and is becoming worse with each new model. It does not have the ability to build complex software beyond a CRUD app (would you use a kernel that was entirely vibecoded? would you trust it the way you trust the Linux kernel?). Secondly, because OpenSource does not discriminate who gets to enjoy the freedom you granted.
You decided to "work for free" when you decided to distribute as OpenSource. If you don't want to work for free, maybe OpenSource is not for you.
The whole point of open source license is that they are a legal document that can be enforced and have legal meaning. It's not just a feel-good article. Your argument is like saying to a client who you are drafting a contract to and say "oh yeah don't worry about the word by word terms in the contract, wink".
Also, this "non-AI" license is plainly not open source nor is it permissive. You can't really say you are a fan of open source when you use a license like this. The whole pt of the MIT license is that you just take it with no strings attached. You can use the software for good or for evil. It's not the license's job to decide.
There is nothing wrong with not liking open source, btw. The largest tech companies in the world all have their most critical software behind closed doors. I just really dislike it when people engage in double-speak and go on this open source clout chasing. This is also why all these hipsters startups (MongoDB, Redis, etc) all ended up enshittifying their open source products IMO, because culturally we are all trying to chase this "we ♥ open source" meme without thinking whether it makes sense.
If people say they "truly love open source", they should mean it.
I meant the enforceability of such clause: to the extent of my limited understanding of law, you would need to at least appear to prove that: someone has breached the agreement by, for example, using your code to train AI. I am not sure how it is possible.
However, I used many tech stacks including Hexo navy theme, Docusaurus, Docsy but ended up creating my own setup with Hugo. If you can see, in the project it's more or html/css that can be used with any builder.