I built my own little CMS#

After years of writing the pages of this website inside my code editor, it feels strange to write this journal entry directly in the website. That's because I've moved away from my static site generator to fall back to my first love of the 2000: a CMS!

Which is curious, because I had been avoiding them! I've managed several websites in the last 20 years, most of them were made with a CMS, and I always found it too complicated. Why a database to store text? Why is this giant admin dashboard necessary? Why so many updates all the time? Why so many images? What do you mean I shouldn't have done chmod 777 / and now my database is broken?!

Building my own SSG for fun#

So when came the time for me to rebuild my own website, I wanted something simple: text files! Now that's simple! That's something I understand! And there are numerous Static Site Generators (SSG) around, I should just pick one!

But inspired by my Merveilles folks, I went further and questioned everything. Do I like my content spread in dozens of files I can't remember the name? No! Do I like enclosing everything inside separate folders and navigating inside? That feels like navigating the Wordpress admin, yuck! Do I even like using Markdown? Kindaaaaaa? I like the titles, not the image markup, and it's missing so many cool HTML attributes!

So, around 2020, I built my own thing: a single giant text file I can CTRL + F inside, a single giant image folder where I drop everything, and my own markup language so I can use <video> and <dl> tags! It was made with a mix of JavaScript files for parsing and writing, and shell scripts to convert images and launch a basic developer environment. To be honest, it was a complicated and frail setup just to put some pages on the internet.

Nonetheless, I had tons of fun building it! It fitted me, and I learned a lot. After a few years, I moved the HTML printing part to a SSG engine (Lume and then Eleventy) and it made it more stable (more info here) while reducing maintenance.

But there was still too much friction. The website was spread between 4 git repositories (open source code, private text files, private images, private production build) and required to ssh to the server to pull updates. When you're fixing a typo for the fourth time, it gets really annoying.

Using the computer is a pain#

When I started drawing again in 2022, I wanted to share my progress on my own website, of course! This is when I realized static site generators are terrible for sharing images (at least mine was).

1. I took pictures of my drawings with my phone. I had to transfer them to my computer.
2. Once transferred to the computer, I had to copy them into the image folder of the website.
3. Then I had to create or edit a page and put my specific syntax to insert them, while remembering their file names.
4. Then commit everything, push, ssh to prod, pull again, etc.

Now that's friction.

This completely killed my ambition to share my drawing progress. Even outside of the laborious steps to put a few images on the internet, doing it meant I had to sit in front of the computer and engage with developer tools to do so.

The sitting in an office chair in front of a screen position was/is still deeply associated to work in my brain, and not enjoyable or relaxing at all. After I burned-out due to work in late 2023, I wanted to be even more as far as possible from anything that reminded me of it, which included my desk and computers.

And so, it was time for a change.

I'm building a team stack#

In 2024 I continued drawing, I went out more, and I was struggling to become a freelancer. In May, I wrote about how I felt the frontend web developer role was shrinking, and that I needed to move to a more full-stack role, which meant doing backend stuff.

And what better reason could I have to do backend than entirely redoing my own website?! Stars aligned, and I set up a loose plan with these constraints:

1. I should be able to publish on this website from my phone, especially upload images easily. I shouldn't struggle with markup for them!
2. If I publish from my computer, it shouldn't be using developer tools. If I open them, it's for adding new features or fixing bugs only!
3. I will store the content in a database to relearn the basics of SQL and shift my mindset from files to database. It's been years since I wrote a query, it's time!
4. I will use a statically typed programming language to move away from my JavaScript habits. Even better if I can use a true IDE and/or a debugger!
5. The programming language I will use should be easy to use, a good learning tool with good resources online, and in-demand on the job market. I would enjoy learning Gleam but gotta be realistic, doing backend is already a big change in my habits!
6. Everything should be easy to deploy, maintain and update. I don't want to fight dependencies and hosting issues, complicated setup, or depend on an hosting platform free tier!
7. I will reuse the same templates and design and bring the website back to feature parity with the existing version. I should not get distracted by frontend code!

After considering all this, I went with the Go programming language and a sqlite database. I was already attracted by Go after seeing a previous colleague work with it, it has a good STDLib, and tons of quality packages. As for sqlite, it has the benefits of just being a file, which fits me well since, you know, I like files.

But most importantly, Go has good and up to date learning resources online: Go Tour, Go By Example, 50 shades of Go, and many more. I was especially interested by Alex Edwards' Let's Go and Thorsten Ball's Writing an interpreter in Go.

Go, Go, Penguin!#

I started working on this new version in February 2025, following Alex Edwards' book, and made good progress. I modified the database and code structure to fit my needs and it went smoothly. Outside of error handling (go to hell if err != nil) and avoiding dependencies that requires external libraries or cgo, I found the language to be pleasant to work with, and didn't regret choosing it.

What bothered me a bit tho, is the good but could be better developer experience. I installed air to have live reloading on save. Despite the project being small, it still took two to four seconds to rebuild and run the code, which isn't a lot, but coming from the JavaScript world, feels slow and to be honest, a bit dated. When I see C# time compilation at my job, I really think backend development needs to invest on this aspect.

But what was the most important missing tool was a modern CSS compiler. Outside of a SASS compiler, I found nothing?! I suppose Go projects use the JS ecosystem for these tasks, but I didn't want that. I just wanted to run go run and have everything compiled. So I downloaded a binary of Lightning CSS CLI and added a build step in Air that compiled my CSS. Not perfect, but waaay better in my book than using npm.

Building the thing#

Of course I underestimated the amount of work involved. Displaying pages from the database was easy. But managing page parents, visibility, image upload, RSS feed, user signup and login, as well as security, if not hard, just took more time than I anticipated.

Among other things, making an editing experience that is good enough was important. The text is just a classic form, with the main text in an auto-sizing <textarea>. But images, my main focus, needed to be easy to upload and insert. So I did a bit of JavaScript to automatically insert the markup on upload, reposition the cursor where the alt text needs to be written, small details like that.

I also added a preview of the page directly next to the editor, keyboard shortcuts to create or edit a page, better visibility settings for pages (public / unlisted / private). A few efforts like those will smooth my user experience, and I have more ideas in the same vein I haven't started yet.

Overall it was a good reintroduction of backend web development concepts. The project itself is well organized and I can add new features easily, which I intend to do: a time tracker, a mood tracker, galleries, and more! The fact I use a database opens a lot of possibilities.

And you might be thinking, nice, I would like to try that! and poor reader, I have bad news.

I won't open source it#

Almost all my code projects have been open sourced with the The Anti-Capitalist Software License, but unfortunately this CMS won't be part of this tradition. There are three main reasons for this.

It requires refactors and planning#

This project has too many things hard coded. If that's not an issue for my personal use, open sourcing the project would require removing my design, add a table for static values, write better documentation, create builds for different operating systems, create a public repository, fork it to add back my own design, etc.

It's a lot, and as I said earlier, I intend to spend less time on the computer, not more. If people really want a CMS, there are dozens of offers out there that can probably fit their needs (use Kirby). I feel that not open sourcing my CMS will not change anything.

I don't entirely own the code#

I followed Alex Edwards' book very closely, and if I made big changes to the point it's not the same project at all in the end, all the structure, a good amount of the code, how things are named, come from the book. Basically, I cannot take ownership of the entire code base and thus, cannot share it. I tried contacting the author on this topic but got no answer.

There's AI generated code inside#

The title says it all, I don't feel like distributing a project with AI generated code inside. Even if it's only 200 lines, it feels like a moral failure from myself, a failure that won't happen again. I wrote about how and why I used an AI in this blog post if you are curious.

Now, if Alex Edwards gives me the authorization, and I find some time to clean things, and I manage to rewrite the AI code, I could open source it. But that's of lot of conditions, and again, this CMS exists to allow me to spend less time on the computer, not more.

What's next#

Lot of things! I have new features to do, I have a big cleanup of old pages going on. Many of them are outdated, or I don't want them online anymore. I also want to start publishing a few of my drawings, especially the creation steps. I have a lot of pictures of drafts, sketches, failures, and want to share the process.

Also expect more entries in the journal. They are so easy to write now, that I may allow myself to publish more often. I will also write details about the CMS and its details inside a dedicated page.

Thanks for reading, if you have remarks or suggestions, you can contact me by email or social networks. See you around!