Ending the Season Images

In October I wrote a post about a little experiment I implemented. An experiement I wanted to build since I was a teen. Now I’m removing this experiment again.

To recap in short, back in the days when I started to create websites, I was fascinated by the idea that the design of a website (or at least a header image) depicts its own little world, with its own simulated weather and urban scenes and people living there. So I did it, with AI, which renewed the header images every 6 hours.

The magic wore off kinda quickly. It was neat to see how it added little scenes around halloween, christmas and new years; but it was also predictable that it will create those scenes. Those special scenes weren’t actually special anymore. And over time, it felt like uninteresting noise. If an artist had created them, it would’ve been much more interesting. Even though it wasn’t 100% AI slop because it had an interesting twist to it, it was still: just AI. People don’t just care about the art, they care about the artist.

I never wanted to keep those images here forever, and I’m happy this idea is now out of my head.

Here are a few oopsies that happened during the experiment:

• To simulate the weather, the AI is prompted with the weather it generated for the previous days, to create a new weather for “today”. It then uses this weather to write a new prompt for the actual image. But it started to write small scenes into the weather report itself, so it continued to reuse this same scene, and for a while all images were in a town with cobblestone streets and a church and a riverside.
• The images need a vignette, which was added to the image in a second step: it first creates the image without the vignette, and then uses this image to generate another image with the vignette. I thought that OpenAI will automatically detect the image aspect ratio to generate a new image with the same ratio. But that was wrong, it started to create square images. So for a while, the vignetted images were weirdly cut off and too small.
• During the React2Shell situation, the image generation halted because I didn’t redeploy the cron. While I updated the Next.js version in my monorepo, there were no changes to the cron (because it doesn’t use Next.js) and the deployment still had the vulnerable version of Next.js installed which we didn’t allow to run on Railway anymore.
• The AI was prompted to create scenes in a german city. But it did not create fireworks at midnight 2025 → 2026, and no streets littered with fireworks, which is just unrealistic af.

Upgrading to Tailwind v4.0

On 22 January, 3 days ago at the time of writing, Tailwind v4.0 was released with some major changes. I decided to upgrade today, and the upgrade path was mixed to be honest!

Reading less short message social media

I stopped scrolling through Bluesky for a month, and I really enjoyed that month.

Even though Bluesky and Mastodon are much nicer places than Twitter, I realized that I don’t enjoy the experience of scrolling through short message social media. There are a few posts here and there that are nice or funny or interesting, but if there’s just a one post that I don’t want to read or think about, the whole experience is ruined for me.

It’s not about keeping your feed clean of extremism and other bullshit. It was easy to keep my feeds clean on Bluesky and Mastodon. But people think and post about a lot of different things, and I’m just not interested in all of them, nor do I want to spend any amount of mental capacity thinking about them. Scrolling past them is difficult. I have to force myself not to read something I’m not interested in. And that just makes it not a great experience.

I subscribe to a YouTube channel because I’m interested in the kind of content they make, and I assume that future content will be similar. And I follow people on Instagram because I like the pictures they post. But short message services just give me too much variety in what to expect.

So, I will continue what I did for a month. I deleted the Bluesky app from my phone and removed it from my browser bookmarks. I’ll still cross-post my posts there, because of course I want to reach an audience. And maybe I’ll post the occasional meme there. (Why not post them here?) But for now, I don’t want to consume text feeds.

URL Fragments and pushState() are weeeiiird

Yesterday I learned two weird things that happen when you use pushState() to navigate to a page with a URL fragment:

1. The CSS :target selector doesn’t work. You can use :target to style an element that is the current URL fragment when doing a full document load, but not with pushState! This is also documented on MDN:

   The target element is set at document load and history.back(), history.forward(), and history.go() method calls. But it is not changed when history.pushState() and history.replaceState() methods are called.

   But that’s weird! Why not? I would argue that it makes :target a little bit unusable in modern web applications. Even though it’s such a useful feature!

2. The hashchange event doesn’t fire. Even though the hash changes, the event doesn’t fire. This is also documented on MDN, but oddly enough it’s documented in the pushState docs, and not in the hashchange docs.

   Note that pushState() never causes a hashchange event to be fired, even if the new URL differs from the old URL only in its hash.

   That’s weird! And unexpected. This note should be included in the hashchange docs. Might be a good opportunity to open a small pull request.

Update: I did indeed open a small pull request and the hashchange docs now also explain this behavior.

Werner by Herzog

wait a second i know the synthesizer why don’t i use the synthesizer

There are a few things I always wanted to do with AI. This is one of them.

Fish is a great shell that simplified my dotfiles

I’ve been a zsh user for a long time, though I’ve had a bit of a love-hate relationship with it. It’s cool once you get it configured, but there’s so much to configure, and from time to time things would just break or the shell would get annoyingly slow.

If you’re using Next.js’ Middleware for authorization, you’re doing something wrong

Whenever the topic of authorization in our Next.js apps came up at Gigs, I had a very strict opinion and rule: we don’t use the middleware for authorization. We can use the middleware for some optimistic UI patterns, like an early redirect when a user is logged out, but never as a means to grant a user access to some data. I’m not saying this because I hate the middleware, or because it’s an easily predictable vulnerability, but because of the way the Next.js middleware sits in an application.