blog.responsive.ch

Hopping off the (SSG) framework train

Fri, 07 Nov 2025 00:00:00 GMT

Three years ago, this statically built blog made the journey from Gatsby to Astro. Astro's major version was 1 at the time. Now it's 5. Every major version of a framework comes with breaking changes. While they are mostly intentional, they might still require spending time understanding and implementing them.

So when I stumbled upon the following (non-public) post on Mastodon the other day, it hit a nerve:

this week i've lost several hours upgrading a site from Astro v4 to v5. really looking forward to doing this again for v6 in a few months 🫠 [...] i would like to rewrite my personal website without any sort of framework or static site generator.

I was immediately nerd-sniped and knew what to do on a Sunday train ride to sunny southern Switzerland. What I ended up with is 400+ lines of JavaScript:

build.js transpiles Markdown files to HTML, creates a full-text RSS feed and bundles client-side scripts.
postprocess.js resizes images and transpiles and minifies styles.

How it works

HTML and RSS

I chose Marked to compile posts written in Markdown to HTML because it comes with 0 dependencies and is well-documented. There are two plugins in use: marked-shiki to add syntax highlighting to code blocks and marked-footnote. Metadata like title, date and abstract is parsed using front-matter.

The only outraging thing I stumbled upon so far: Marked seems to be unable to parse custom element names containing emojis.

The full-text RSS feed is built with the help of xml because I still don't understand CDATA. Fun fact: The full-text part was actually more complex when still using Astro v1.

Styles

The single CSS file is copied as is and then postprocessed using LightningCSS. The processing consists of transpiling new syntax based on a Browserslist config (flattening CSS nesting, rewriting color functions like lch etc.) and minification.

This is mostly optional: Should the postprocessing step make any issues at any point, I could just drop it and everything would still work fine (though styles would not be minified and some rules would be not be interpreted in older browsers).

Responsive images

The built HTML is parsed using LinkeDOM to find all img elements with relative src URLs. Using Sharp, images are transformed to WebP and resized based on a pre-defined list of dimensions.

Before:

![form route after POST request](media/form-post.png)

After:

<img
  height="538"
  width="800"
  loading="lazy"
  sizes="auto"
  srcset="media/form-post-400.webp 400w, media/form-post-800.webp 800w"
  src="media/form-post.png"
  alt="form route after POST request"
/>

So the postprocess script adds an srcset attribute with a few image sizes based on the original size of the image.

The magic part is the added sizes="auto" as it frees me from figuring out specific sizes for specific images on specific viewports. Instead, the browser will pick the proper size. It has to be combined with loading="lazy" so it would not be appropriate for keyvisuals, but works great for my content images.

This is totally awesome.

I really hope it will be part of Interop 2026 as it's currently Chromium-only. Until then, the following step will bundle a polyfill for other browser.

This processing step is optional, too. We'll still get working images should it ever fail, they are just larger than necessary. Same for non-Chromium browsers unable or unwilling to load and interpret the polyfill.

Scripts

The layout component references a single file:

<script src="/scripts/index.js" type="module"></script>

It is created from a single entrypoint using esbuild. There are some hoops to jump through in order to map the Browserslist config to esbuild's target option, but nothing too fancy.

Deployment

A two-stage Docker build first runs the build and postprocess scripts and serves the result with nginx. A custom config file makes sure that we have a nice 404 page.

This should work everywhere we can run a docker container. As a fan of fly.io, I have chosen their platform and deploy via their default GitHub action.

Limitations

Limitations?

Okay, for one, there is no real development server. Instead, I serve the dist/ folder using macOS's built-in python3 -m http.server -d dist. A simple node --watch-path=./src ./bin/build.js rebuilds everything on every change of a markdown file and I manually reload the browser window whenever I feel like it. Which is not very often.

Second: Test coverage. Works on my machine.

Third: I don't yet understand the ETag caching behavior used by nginx (specifically, when my browser should decide to fetch updated styles or client-side scripts).

Summary

Tired of regularly upgrading your SSG framework? There are two options:
1. Replace the framework with another, fancier framework.
2. Build your own framework.
sizes="auto" is the best.

Running ImageMagick on older macOS

Thu, 31 Jul 2025 00:00:00 GMT

We reanimated an old MacBook for the kid so he could download pictures of planes, trains and automobiles, and create his own memory sets (a card game which is apparently called concentration in non-German speaking countries). Turns out the latest macOS running on that particular hardware (10.15 Catalina) does not yet support WebP or AVIF images outside of a browser. No problem, let's brew ourselves some ImageMagick so we can convert them to PNGs.

Nope. Turns out a dependency (an ingredient?) of that formula, a recent OpenSSL version, assumes as specific Perl dependency is always present. Not on this machine. As some people on the internet recommended against manipulating the system version of Perl, I went with a new homebrewed one and installed the missing IO::Socket::IP via cpan. Still no luck, as installing OpenSSL apparently ignored my new perl version. At some point this was working somehow, but then I stumbled upon the next failing dependency.

I was expecting something similar to npm's overrides to exist, allowing me to pin an old version of any incompatible dependeny. But based on what I gathered from discussions in Homebrew's issue tracker, that is not something they want to provide. Which is very unfortunate for my case but totally understandable from an open-source software support point-of-view.

So I gave up and turned to Docker:

FROM debian:latest
RUN apt-get update && apt-get install -y imagemagick
ENTRYPOINT ["magick"]

After building this image with docker build . -t imagemagick, it can be used to convert all .webp and .avif files in the current directory (recursively) to PNG:

for f in $(find . -name '*.webp' -o -name '*.avif'); do
  docker run -v $(pwd):/i imagemagick /i/$f /i/$f.png
done

However, this image has a ridiculous size of 380 MB. So let's pick a smaller base image:

FROM alpine:latest
RUN apk add --no-cache imagemagick
ENTRYPOINT ["magick"]

While this reduces the size to 33 MB, it has the slight disadvantage of not working:

magick: no decode delegate for this image format `AVIF' @ error/constitute.c/ReadImage/746.
magick: delegate failed `'dwebp' -pam '%i' -o '%o'' @ error/delegate.c/InvokeDelegate/1920.
magick: unable to open file '/tmp/magick-WH2QY7r79RAmEmO-qFYO0Lv219JnOAbk': No such file or directory @ error/constitute.c/ReadImage/785.

So let's add the missing packages:

FROM alpine:latest
RUN apk add --no-cache imagemagick libwebp libheif
ENTRYPOINT ["magick"]

This increases the built image's size to 51 MB (~0.5 MB for libwebp and the rest for libheif), but we are still almost 90% below the initial size. 🎉

So as long as Docker runs on macOS Catalina, we are probably safe.

SVG Sprites for HTML and CSS

Tue, 30 Jul 2024 00:00:00 GMT

SVG sprites are a great way to serve icons. They have been around for quite some time.

The basic approach:

Add each icon as a to a single sprite-symbols.svg file:

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol viewBox="0 -960 960 960" id="search">
    <path
      d="M784-120 532-372q-30 24-69 38t-83 14q-109 0-184.5-75.5T120-580q0-109 75.5-184.5T380-840q109 0 184.5 75.5T640-580q0 44-14 83t-38 69l252 252-56 56ZM380-400q75 0 127.5-52.5T560-580q0-75-52.5-127.5T380-760q-75 0-127.5 52.5T200-580q0 75 52.5 127.5T380-400Z"
    />
  </symbol>
  <symbol viewBox="0 -960 960 960" id="close">
    <path
      d="m256-200-56-56 224-224-224-224 56-56 224 224 224-224 56 56-224 224 224 224-56 56-224-224-224 224Z"
    />
  </symbol>
</svg>

Render SVG with use element. Reference specific symbol via fragment identifier:

<svg class="icon">
  <use xlink:href="sprite-symbols.svg#search" />
</svg>

Set color via CSS:
```
.icon {
  fill: currentColor;
}
```

The result:

How to reference the sprite in CSS?

What if we are unable to control the HTML and want to render the icon via CSS instead?

Let's add a background image:

<style>
  .var-background::before {
    background-image: url(sprite-symbols.svg#search);
    /* ... */
  }
</style>

<button type="button" class="icon-button var-background">Search</button>

Unfortunately, the icon is not rendered:

For this to work, we need to expose a element in the sprite. Fortunately, it can be combined with our existing via a intermediate:

<svg
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
>
  <symbol viewBox="0 -960 960 960" id="search">
    <path
      d="M784-120 532-372q-30 24-69 38t-83 14q-109 0-184.5-75.5T120-580q0-109 75.5-184.5T380-840q109 0 184.5 75.5T640-580q0 44-14 83t-38 69l252 252-56 56ZM380-400q75 0 127.5-52.5T560-580q0-75-52.5-127.5T380-760q-75 0-127.5 52.5T200-580q0 75 52.5 127.5T380-400Z"
    />
  </symbol>
  <use xlink:href="#search" width="960" height="960" x="0" y="0"></use>
  <view id="search-view" viewBox="0 0 960 960" />

  <symbol viewBox="0 -960 960 960" id="close">
    <path
      d="m256-200-56-56 224-224-224-224 56-56 224 224 224-224 56 56-224 224 224 224-56 56-224-224-224 224Z"
    />
  </symbol>
  <use xlink:href="#close" width="960" height="960" x="0" y="960"></use>
  <view id="close-view" viewBox="0 960 960 960" />
</svg>

Now we can use the fragment identifier of the new element:

.var-view::before {
  background-image: url(sprite-hybrid.svg#search-view);
  /* ... */
}

The updated result:

How to change color on hover/active?

mask-image to the rescue. Instead of using background-image, we set a background color and use the icon as a mask:

.var-mask::before {
  background: currentColor;
  mask-image: url(sprite-hybrid.svg#search-view);
  /** ... */
}

The final result:

How to automate this?

I'm currently using the highly recommended svg-sprite library to generate SVG sprites from a folder of icons. At the time of writing this article, it does not yet provide a hybrid mode. However, since its compile method returns both the generated SVG and all shapes, we can use the symbol output mode and manually extend the generated SVG with a for each symbol by looping through the shapes.

Minimal Node.js server

Wed, 11 Oct 2023 00:00:00 GMT

I absolutely love building small web applications.

We have to scroll too long to find our son's favorite kind of bedtime stories on srf.ch? Let's extract them and create our own listing where we can keep track of what we have watched, too.

I'm annoyed with the local library's (single-page) application because it takes 25 clicks to see the books we have borrowed? Let's write a Puppeteer script to export them on an a regular basis and list them on a website along with the current opening hours.

My basic requirements for these mini-projects:

Routing
POST request body parsing
Watch mode during development

In the old days, I would usually opt for something like Next.js. And whenever I wanted to change something later, I had to spend much more time maintaining dependencies than actually writing code.

My new setup:

"dependencies": {},
"devDependencies": {}

What it does

The demo app has two routes, one of them handling POST requests (assuming the x-www-form-urlencoded content type of a basic

GET /:
GET /form:
POST /form:

What we need

This is the complete code:

// @ts-check
import http from "node:http";

const port = process.env.PORT || 3000;

/**
 * Parse POST request body
 * @param {import('http').IncomingMessage} req
 * @returns {Promise<{ [key: string]: string | string[] }>}
 */
async function parseBody(req) {
  const body = await new Promise((resolve) => {
    let data = [];

    req
      .on("data", (chunk) => {
        data.push(chunk);
      })
      .on("end", () => {
        const str = Buffer.concat(data).toString();
        const searchParams = new URLSearchParams(str);
        const obj = {};

        for (const key of searchParams.keys()) {
          const values = searchParams.getAll(key);

          obj[key] = values.length > 1 ? values : values[0];
        }

        return resolve(obj);
      });
  });

  return body;
}

/**
 * Render HTML document
 * @param {{ title?: string, content?: string }} props
 * @returns {string}
 */
function renderHtml({ title = "Title", content = "Content" } = {}) {
  return `<!DOCTYPE html>
		<html lang="en">
			<head>
				<meta charset="utf-8">
				<title>${title}</title>
				<style>body { font-family: sans-serif; }</style>
				<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>👋</text></svg>">
			</head>
			<body>
				<h1>${title}</h1>
				${content}
			</body>
		</html>
	`;
}

/**
 * Start server on `port`
 */
http
  .createServer(async (req, res) => {
    const requestUrl = new URL(req.url || "", `http://${req.headers.host}`);

    // Route: `/`
    if (requestUrl.pathname === "/") {
      const html = renderHtml({
        content: `<p><a href="/form">Form example</a></p>`,
      });

      res.writeHead(200, { "Content-Type": "text/html" });
      res.end(html);

      return;
    }

    // Route: `/form`
    if (requestUrl.pathname === "/form") {
      let message = "";

      if (req.method === "POST") {
        const body = await parseBody(req);

        message = `<pre>body: ${JSON.stringify(body, null, "  ")}</pre>`;
      }

      const html = renderHtml({
        title: "Form",
        content: `${message}
					<form action="" method="POST">
						<p>
							<label for="name">Name</label>
							<input type="text" name="name" id="name">
						</p>
						<button type="submit">Submit</button>
					</form>
					<p><a href="/">Back to index</a></p>
				`,
      });

      res.writeHead(200, { "Content-Type": "text/html" });
      res.end(html);

      return;
    }
  })
  .listen(port, () => {
    console.log(`App is running on port ${port}: http://localhost:${port}`);
  });

The most complex part of it is parsing the request body (function parseBody). It would be even shorter if we ignored multiple values with the same key.

And this is the complete package.json:

{
  "name": "my-little-wep-app",
  "version": "0.0.1",
  "type": "module",
  "scripts": {
    "start": "node index.js",
    "dev": "node --watch index.js"
  },
  "engines": {
    "node": ">= 18.11"
  }
}

npm run dev will restart the server on changes to index.js or any of its potential imports. This is courtesy of Node.js 18.11+' native file watcher.

I will never go back.

Custom Website Styles on iOS

Sun, 08 Oct 2023 00:00:00 GMT

I tend to read in the evening. This is what I look like:

Yes, I have mounted my smartphone to the wall.

As websites like watson.ch or vox.com don't seem to offer a dark mode, writing my own custom styles is the quickest solution.

Turns out there is a nice solution for that: Userscripts:

Userscripts is an open source Safari extension that lets you save and run arbitrary bits of JavaScript (and CSS) code for the websites you visit. It implements a code editor right in your browser for a simple method of creating, editing and saving your code.

This is what my custom styles for watson.ch look like:

Toggle code

Free analytics with Fathom on Fly.io

Sat, 19 Nov 2022 00:00:00 GMT

As I'm interested in the number of visitors my own websites are seeing, I need some basic analytics tooling. By setting up my own instance of Fathom Lite, the open-source version of Fathom Analytics, I think I can do this in a fairly privacy-preserving way.

Fathom Lite offers a pre-built Docker image. This is great if you don't enjoy following installation instructions consisting of more than one bullet point.

But where to deploy this image? While being able to use AWS, Azure and Google Cloud in my client projects, I try to avoid them whenever possible. As I'm not really experienced with any of their Configuration as Code solutions, deploying a Docker image and assigning a custom domain would include 25 steps in either of their fun admin UIs.

Meet Fly.io:

Fly.io runs apps close to users. We transmogrify Docker containers into Firecracker micro-VMs that run on our hardware around the world, and connect all of them to a global Anycast network that picks up requests from around the world and routes them to the nearest VM.

They had me at transmogrify. But what I actually like the most about it: Deploying an image like the Fathom one takes about a minute (assuming flyctl has been installed and your are logged in).

Basic setup

Create the application:
```
flyctl launch --image usefathom/fathom
```
This will prompt us for a name and a region. The result is a configuration file with the following content:

fly.toml

Moving to Astro

Fri, 18 Nov 2022 00:00:00 GMT

Blogs are great. They are my main source of (tech) information and I very much enjoy following people like Jim Nielsen, Dave Rupert or Simon Willison. Their feeds have a cozy home in my RSS reader.

When I decided to do more writing of my own, the first step was crystal clear: Replace the underlying framework of this blog so the actual writing part can be postponed.

As a responsible web developer, I'm obligated to spend at least 75% of my time evaluating new web frameworks. And there is no better way to do this than using them on ~~important customer~~ personal projects. When setting this blog up two years ago, Gastby was shiny. It worked out fine and I learned the basics about the framework. (What I took away from it was that it felt a bit over-engineered.)

Getting back to it after more than a year and on a computer with a different processor architecture, I was obviously unable to run npm install without a few cheeky errors and warnings. As upgrading to the latest version would have meant following three different migration guides in sequence, I just picked up a new shiny object: Astro.

I had been closely following Astro's development and very much sympathized with its general philosophy:

[...] cover a wide range of styles in the noise field, from space music to psychedelically-tinged harsh noise

Never mind, wrong Astro. This one here:

Zero JavaScript Runtime. Astro renders HTML on the server and strips away any remaining, unused JavaScript.

Now you might think this is irrelevant for a blog with zero client-side JavaScript to begin with. Great thinking! However, there are frameworks whose main purpose is to generate JavaScript out of no JavaScript so they can send it to the visitors of your website because they hopefully are JavaScript afficionados, too.

My Astro Takeaways

It's fun! Even the installation process, thanks to Nate Moore's great work. ¹
There are less dependencies:
- node_modules before: 479.8 MB for 59'083 items
- node_modules after: 242.1 MB for 10'110 items
As everything below 250 MB does not count as a real node_modules folder by law, we basically have no dependencies.
I'm missing the possibility to add the complete post to the RSS feed (currently a limitation of using MDX).
The community is really welcoming. When I opened a PR to add support for footnote customizations in Astro's MDX integration, Sarah Rainsberger and Ben Holmes ² were very helpful and kind.

Setting up a Mac

Sat, 13 Feb 2021 00:00:00 GMT

First thing I do is some login screen gardening: Displaying my best self-portrait and adding contact information. This way, I don't have to remember taking my MacBook with me when leaving the coffee shop.

The first app I install is 1Password. It allows me to log into Github to download my .zshrc, .gitconfig and other preference files. Like the cool kids, I started out with a setup script. However, I always forgot to maintain it and ended up with outdated preferences. Now, I just push the system and application preferences I care about (e.g. com.apple.dock.plist) to Github right before setting up a new machine.

At some point I realize I have to install the Xcode Command Line Tools for Git to work. Depending on whether I update macOS sometime in between, I'm doing this multiple times as Apple pretends to lose them with every new version. Note to self: xcode-select --reset will usually be a quicker solution than the often recommended deleting an re-installing.

The second app I can't live without is Alfred. Highly recommended by Batman, Alfred not only helps me launching applications, but also remembering my clipboard history, showing my current IP or finding processes to kill. A typical workflow while writing frontend code:

Opening the docs for a specific feature in Dash:
Checking its browser support:
Finding a polyfill on npm:

The third one is Rectangle. It is used by fellow CEOs and allows me to move around windows via keyboard (or mouse). When working on a widescreen display, I usually want to have two windows next to eachother. So whenever I open an app, I press ^⌥← or ^⌥→ to use one or the other screen half. Another important use-case is catching up with SNL in an efficient way:

Moving on to the menu bar, I use Dato to display the current week number and have immediate access to the calendar. As you can see, I'm very good at calendaring:

The other menu bar app I approve of is Lungo. Why should your Mac be able to sleep when you can't?

After having installed Docker, Homebrew and nvm, it's time for some atypically large electrons: VS Code, Slack and Notion are the applications I spend most of my screen time in. I very much enjoy the fact that they are written in JavaScript. While, like any reasonable Swiss citizen, I have mixed feelings about some of them being developed in Zürich.

Last thing to do is setting up Arq to back up my files into a glacier, and installing Dropbox to gain access to everything not living in a Git repository.

Fun with polyfills

Thu, 31 Dec 2020 00:00:00 GMT

Using new JavaScript syntax or features while still supporting older browsers requires us to transpile and polyfill our code before deployment. The tool of choice is usually Babel. Its preset-env plugin hides most of the complexity and allows us to simply specify a list of browsers to support, sit back and enjoy the ride. However, the ride might take an unexpected turn when analyzing the generated code.

Let's say we want to log all links on a page:

const links = document.querySelectorAll("a");

links.forEach((link) => {
  console.log(link.href);
});

For this to work in IE 11, we would want to rewrite it to the following code:

// Polyfill missing `.forEach` on `NodeList`
if (window.NodeList && !NodeList.prototype.forEach) {
  NodeList.prototype.forEach = Array.prototype.forEach;
}

// Use `var` over `const`
var links = document.querySelectorAll("a");

// Replace arrow function
links.forEach(function (link) {
  console.log(link.href);
});

Babel slightly disagrees and rewrites it to the following code instead:

Toggle code

Controlling our blinds via Siri

Sun, 15 Mar 2020 00:00:00 GMT

There are two approaches to automating window blinds:

Using existing, proven systems like Somfy.
Vastly overestimating your engineering capabilities and building your own DIY system.

Let's focus on the latter as the former is ridiculous.

There are three main components to this:

Remotes to control the whole thing. Usually hand-held ones or special wall switches.
A hub / control center / base station relaying these commands to the receivers. This is optional in case the remotes are capable of interacting with the receivers directly.
Radio controllers receiving these commands to manage the blinds' power supply.

Being a devoted member of the Apple cult, using a Homekit-compatible setup was an obvious choice. This would allow us to use our existing devices instead of having to buy remotes which are a) often limited in how many blinds they can control and b) rather expensive. And not from Apple.

For the radio setup, I decided on the Z-Wave protocol since the ecosystem of both hardware and open-source software seems vibrant. I went out (just kidding, I never left my desk) and bought the following Z-Wave-compatible radio controllers:

Aeotec Nano Shutter	Fibaro Roller Shutter 3	Qubino Flush Shutter

If you look closely, you can see that the Nano Shutter survived being short-circuited for scientific reasons.

I like the Nano Shutter the best. Mainly because its physical button not only allows you to control Z-Wave inclusion/exclusion (connecting/disconnecting them to the Z-Wave stick), but also to control the blinds. So if somethings goes wrong network-wise, you can still manually close or open the blinds via this button.

To send commands to the controllers, I chose an Aeotec Z-Stick Gen5 and plugged it into my MacBook. Connecting the controllers to the stick uncovered the first issue with the Qubino one: The manual told me to either Press push button I1 (which would have required me to connect an external, physical button to this input) or Press service button S (only applicable for 24 V SELV supply voltage) (which is a physical button on the controller, however, I was using 220 V). A nice fellow in a home automation forum convinced me to use the latter anyway: In fact 220V also works but you have a risk of electro shock while pressing that stupid S button.

Still alive and optimistic, I opened my code editor. Being fluent in the only reasonable programming language there is, JavaScript, my first attempt was using Homebridge. I went through every Homebridge-Z-Wave implementation I could find but struggled to consistently send reasonable commands to the controllers. Most of the time, they showed up as light bulbs in Apple's Home app. Which is not completely unreasonable, but still not ideal.

At some point, I decided to have a look at Home Assistant, a very well-documented open-source home automation solution. While I was unsuccessful with the Docker setup and had to jump through some hoops to run it natively, I was able to connect both the USB stick and the controllers and they properly showed up as window blinds in my Home app. 🎉

After my wife showed a complete lack of understanding for the fact that the blinds would only work if my laptop was up and running, I ordered my first Raspberry Pi. This was as much fun as anticipated, definitely recommended. The only thing not immediately obvious to me was that I had to reflash the SD card bundled with my starter kit with Raspbian since the default installer apparently requires connecting a screen and keyboard to the Pi (which I refused).

Everything else was smooth as an android's bottom. That is until I wasn't able to connect the Z-Wave UBS stick. The corresponding Github issue alternatingly blamed Raspberry and Aeotec and stated that the problem was both definitely solved and definitely not solved with every existing USB hub stuck between the Pi and the stick. Luckily, the first cheap hub I found worked out just fine.

Z-Wave stick connected to Raspberry Pi via simple HAMA USB hub.

The only thing left was configuring Home Assistant. Which was a great experience. A very intuitive UI (which I can't say for paid alternatives like this one) and, again, really well-documented. After discovering that the Nano Shutter did not consistently show up in Home after restarting the Pi, a quick search through their Github issues relevaled that delaying the start of the Homekit integration solved the issue.

So this is my life now:

Hey Siri, please open the blinds. I want to check the weather to see which pair of sweatpants I should wear for lunch.