Show HN: DD Photos – open-source photo album site generator (Go and SvelteKit)

I was frustrated with photo sharing sites. Apple's iCloud shared albums take 20+ seconds to load, and everything else comes with ads, cumbersome UIs, or social media distractions. I just want to share photos with friends and family: fast, mobile-friendly, distraction-free.

So I built DD Photos. You export photos from whatever you already use (Lightroom, Apple Photos, etc.) into folders, run `photogen` (a Go CLI) to resize them to WebP and generate JSON indexes, then deploy the SvelteKit static site anywhere that serves files. Apache, S3, whatever. No server-side code, no database.

Built over several weeks with heavy use of Claude Code, which I found genuinely useful for this kind of full-stack project spanning Go, SvelteKit/TypeScript, Apache config, Docker, and Playwright tests. Happy to discuss that experience too.

Live example: https://photos.donohoe.info Repo: https://github.com/dougdonohoe/ddphotos

github.com

・

52 points

・

dougdonohoe

・

7 hours ago

14 comments

kkukshtel ・ 3 hours ago

Just taking this moment to share something I made from a similar point of frustration — https://mood.site

It's a free online photo gallery app where auth is done through URL query params. You make a board, it gets an edit key, and then if you share that url with anyone else (including grandma) they can upload photos without needing to make an account. You can drag and drop, use the upload button, and it works on mobile as well.

There are lots of other little features as well, but the core thing is just a dead simple (online) photo gallery tool. You can see some sample boards here:

https://mood.site/Prp_-CPS

https://mood.site/WvP4xd6x

https://mood.site/N3kHLWkJ

dumindunuwan ・ 2 hours ago

This can be just a Hugo theme with much lesser code https://themes.gohugo.io/tags/gallery/

  • dougdonohoe ・ an hour 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.

subpixel ・ 5 hours ago

This is really great. At first it seems a tad over-engineered but I admit the state of the art has progressed since the days of using Yeoman to scaffold a Jekyll site. Also the fact that you don’t use Hugo deserves to be congratulated.

giancarlostoro ・ 7 hours ago

I have a similar frustration, on my Surface Book 2, for some reason the Photos default Windows app is sluggish to death. I have to scour all sorts of third party applications to finally find one that loads correctly. I'm using an extremely vanilla configured Windows too. I rarely open that laptop anymore because of all the bloat. Someday I'll smoosh over Windows and just dump Linux on top of it, even though the support for Linux isn't the greatest.

The Photos app on Mac irritates me too, you cannot just force it to scan everything, it has to "do it in the background" which feels like never.

I've looked at all sorts of alternative photo gallery programs, and it feels like none come close to what I wish Photos was like, without being slugs.

  • uberwindung ・ an hour ago

    i am working on one that will run natively on mac, windows and linux. let me know if you are interested in an early access version.

thatcherc ・ 6 hours ago

This looks great! I've been using ThumbsUp[1] for a similar purpose (creating a gallery of photos I can push S3), but adding album and photo captions required some un-ergonomical tricks. I'll try this out!

[1] - https://github.com/thumbsup/thumbsup

  • dougdonohoe ・ 6 hours ago

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

JanoMartinez ・ 6 hours ago

Nice project. I like the approach of using static generation instead of building a full backend for something that’s mostly read-only.

Did you find any challenges handling large numbers of photos when generating the indexes?

  • dougdonohoe ・ 6 hours ago

    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.

mandubird ・ 6 hours ago

Interesting approach.

Curious how this behaves with larger datasets or longer sessions.

  • subpixel ・ 4 hours ago

    I’m assuming the build step doesn’t resize images that have already been processed. Other than that this approach seems to handle plenty of images per album. Albums are a UX principle, so they shouldn’t be very big anyway.

    • dougdonohoe ・ 3 hours ago

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