My first implementation used vanilla JavaScript using the Intersection Observer API, and it worked fine. It took about 30 lines of custom JavaScript and 20 lines of PHP code.

But Drupal now ships with htmx support, and that had been on my mind. So a couple of hours later, I rewrote the feature with htmx to see if it could do the same job more simply.

It's something I love about Drupal: how we keep adding small, well-chosen features like htmx support. Not flashy, but they quietly make everyday work nicer. Years ago, Drupal was one of the first CMSes to adopt jQuery, and our early adoption helped contribute to its widespread use. Today, we're replacing parts of jQuery with htmx, and Drupal may well be among the first CMSes to ship htmx in core.

If, like me, you haven't used htmx before, it lets you add dynamic behavior to pages using HTML attributes instead of writing JavaScript. Want to load content when something is clicked or scrolled into view? You add an attribute like hx-get="/load-more" and htmx handles the request, then swaps the response into your page. It gives you AJAX-style interactions without having to write JavaScript.

To make the photo stream load more images as you scroll, I added an "htmx trigger". When it scrolls into view, htmx fetches more photos and appends them to the right container. The resulting HTML looks like this:

<div hx-get="/photos/load-more?offset=25"
         hx-trigger="revealed"
         hx-target="#album"
         hx-swap="beforeend">
  <figure>
   ...
  </figure>
</div>

The hx-get points to a controller that returns the next batch of photos. The hx-trigger="revealed" attribute means "fire when scrolled into view". The hx-target="#album" tells htmx where to put the new content, and hx-swap="beforeend" appends it at the end of that #album container.

I didn't want users to hit the last photo and have to wait for more to load. To keep the scrolling smooth, I added the trigger a few photos before the end. This pre-fetches the next batch before the user even realizes they are running out of photos. This is what the code in Drupal looks likes:

// Trigger 3 images before the end to prefetch the next batch.
$trigger = array_keys($images)[max(0, count($images) - 4)];

foreach ($images as $key => $image) {
  …

  if ($key === $trigger) {
    // Add htmx attributes to the <div> surrounding the image.
    $build['#attributes']['hx-get'] = '/photos/load-more?offset=' . ($offset + $limit);
    $build['#attributes']['hx-trigger'] = 'revealed';
    $build['#attributes']['hx-target'] = '#album';
    $build['#attributes']['hx-swap'] = 'beforeend';
  }
}

And the controller that returns the HTML:

public function loadMorePhotos(Request $request) {
  $offset = $request->query->getInt('offset', 0);
  $limit = 25;
  $photos = PhotoCollection::loadRecent($offset, $limit);
  if (!$photos) {
    return new Response('');
  }

  $build = $this->buildImages($photos, $offset, $limit);
  $html = \Drupal::service('renderer')->renderRoot($build);
  return new Response($html);
}

Each response includes 25 photos. It continues fetching new photos as you scroll down until there are no more photos, at which point the controller returns an empty response and the scrolling stops.

As you can tell, there is no custom JavaScript in my code. It's all abstracted away by htmx. The htmx version took less than 10 lines of PHP code (shown above) instead of 30+ lines of custom JavaScript. The loadMorePhotos controller I needed either way.

The savings are negligible. Replacing a couple dozen lines of JavaScript won't change the world. And at 16KB gzipped, htmx is much larger than the custom JavaScript I wrote by hand. But it still feels reasonable. My photo stream is image-heavy, and htmx adds less than 0.5% to the initial page weight.

Overall, I'd say that htmx grew on me. There is something satisfying about declarative code. You describe what should happen, and the implementation disappears. I may try it in a few more places to improve the user experience of my site.

I didn't like how Instagram made me feel, or the fact that it tracks my friends and family when they look at my photos. And while it was a nice way to stay in touch with people, I never found a real sense of community there.

Instead, I wanted a space that felt genuinely mine. A place that felt like home, not a podium. No tracking, no popularity contests, no clickbait, no ads. Just a quiet corner to share a bit of my life, where friends and family could visit without being tracked.

Leaving Instagram meant giving up its biggest feature: subscribers and notifications. On Instagram, people follow you and automatically see your posts. On my website, you have to remember to visit.

To bridge this gap, I first added an RSS feed for my photos. But since not everyone uses RSS, I later started a monthly photo newsletter. Once a month, I pick my favorite photos, format them for email, and send them out.

After sending five or six photo newsletters, I could already feel my motivation fading. Each one only took about twenty minutes to make, but it still felt like too much friction. So, I decided to fix that.

Under the hood, my photo stream runs on Drupal, built as a custom module. I added two new routes to my custom Drupal module:

• /photos/$year/$month: shows all photos for a given month, with the usual features: lazy loading, responsive images, Schema.org markup, and so on.
• /photos/$year/$month?email=true: shows the same photos, but stripped down and formatted specifically for email clients.

Now my monthly workflow looks like this: visit /photos/2025/9?email=true, copy the source HTML, paste it into Buttondown, and hit 'Send'. That twenty-minute task became a one-minute task.

I spent two hours coding this to save nineteen minutes a month. In other words, it takes about six months before the time saved equals the time invested. The math checks out: 120 / 19 ≈ 6. My developer brain called it a win. My business brain called it a write-off.

But the real benefit isn't the time saved. The easier something is, the more likely I am to stick with it. Automation doesn't just save time. It also preserves good intentions.

Could I automate this completely? Sure. I'm a developer, remember. Maybe I will someday. But for now, that one-minute task each month feels right. It's just enough involvement to stay connected to what I'm sharing, without the friction that kills motivation.

For those reasons, I set a personal challenge in 2018 to take back control over my social media, photos and more. As a result, I quit Facebook and stopped using Twitter for personal status updates. I still use Twitter for Drupal-related updates.

To this date, I still occasionally post on Instagram. The main reason I still post on Instagram is that it's simply the easiest way for friends and family to follow me. But every time I post a photo on Instagram, I cringe. I don't like that I cause friends and family to be tracked.

My workflow is to upload photos to my website first. After uploading photos to my website, I occasionally POSSE a photo to Instagram. I have used this workflow for many years. As a result, I have over 10,000 photos on my website, and only 300 photos on Instagram. By all means, my website is my primary platform for sharing photos.

I decided it was time to make it a bit easier for people to follow my photography and adventures from my website. Last month I silently added a photo stream, complete with an RSS feed and mailing list. Now there is a page that shows my newest photos and an easy way to subscribe to them.

While an RSS feed doesn't have the same convenience factor as Instagram, it is better than Instagram in the following ways: more photos, no tracking, no algorithmic filtering, no account required, and no advertising.

My photo stream and photo galleries aspire to the privacy of a printed photo album.

I encourage you to subscribe to my photo stream and to unfollow me on Instagram.

Step by step, I will continue to build my audience here, on my blog, on the edge of the Open Web, on my own terms.

From a technical point of view, my photo stream uses responsive images that are lazy loaded – it should be pretty fast. And it uses the Open Graph Protocol for improved link sharing.

PS: The photo at the top is the subway in Boston. Taken on my way home from work.

Also posted on IndieNews.