A new SwedenCpp website is online

For a long time, the SwedenCpp homepage rewrite sat on my personal todo list. This weekend I finally got it done, and a new version of the SwedenCpp website is now online.

eng

Why a rewrite?

There were three main reasons:

  • Add functionality

  • Try out some languages and tools

  • Doing something different, learning something new

New functionality

The SwedenCpp page started years ago with one simple goal: list local meetups. Later I added blogs and videos, but some compromises stayed in place.

One of them was conference videos. I did not include them because they can flood a feed. Over time, many conferences started spreading their releases over weeks, which made this easier to handle.

Last year I built release bots for X (former twitter) and Bluesky. They post new conference videos automatically. I like that functionality, but I do not enjoy using those platforms myself. So I wanted that same functionality directly on the SwedenCpp website.

Another open point was that Meetup closed the old public API some years ago, and upcoming meetups disappeared from the page. I had a new implementation in mind for a while, but no time to implement it. This rewrite was the chance to finally do it.

What the page shows now

So the page now has all the information I care about in one place:

  • upcoming meetups

  • video releases, including conference talks

  • blog posts

  • software releases from tracked projects

  • podcasts, if there are any

It also includes static information about SwedenCpp itself.

This is what I want to see when I visit the page every day. So I mostly built it for myself, but I hope others find it useful too.

Trying out languages and tools

I used the opportunity to compare some programming languages and how suitable they are for this type of application. I also tried different databases.

Go, Swift, or Node.js

I wrote the app three times: in Go, Swift, and JavaScript. Just to see how each of these programming languages feels for this task.

TL;DR: Go made the most sense to me, and I liked it best.

Swift was fun too, but server-side Swift still has rough edges for my use case. In the end, this is again a classic Node.js app, written in JavaScript with @ts-check for some discipline.

TypeScript might have been the better option, but I wanted to try plain JavaScript plus @ts-check. It works fine. Still, for future ECMAScript projects, I will likely use TypeScript again.

Trying out Turso

I experimented with Turso, a distributed SQLite database. It is very interesting, but with the ongoing rewrite in Rust and the current state of the existing client, it did not feel stable enough for this project right now. I even contributed to the Swift client, but those contributions did not move forward.

So I switched to MariaDB for state handling. It works well, and it is also included by my provider, which keeps hosting simple.

Language and Tooling decision

Even if Turso and Swift would have been fun, and even if I liked the Go solution best, I decided to take the well-known route and stay with Node.js and MariaDB.

The argument for Node.js

The Node.js decision was purely practical: my provider has very good Node.js support. I can run it as part of my existing package, while Swift or Go would require a separate hosted solution.

The argument for MariaDB

Similar to Node.js, MariaDB is simply available from my provider. Also, even if I like Turso a lot, there is too much instability with the ongoing rewrite and the state of the current implementations.

Doing something different

I gave each version two weeks. One week to learn the current state of the ecosystem, and one to implement.

Swift had issues with both Turso and MariaDB, so I could not finish that version. Still, adding some database driver code for both was very educational, and it was the most fun.

Go is awesome, and if my provider officially supported running Go apps, I would have used Go.

But Node.js, JavaScript, and TypeScript are also fine. And these days, they can easily become part of the job. Not too long ago I added end-to-end testing via Playwright for a Rust / C++ backend. It’s good to train the scripting muscle memory from time to time.

Summary

I try to do at least one new thing each year, so for 2026 I am already on track. It was fun writing this app because it is very different from what I usually do. And I enjoyed filling the time I have at the moment with learning that produces a usable result.

Disclaimer

This post was written by a human. AI has only been used for spell-checking.