codematle.com
10.04.2025On setting the ground work for future projects and creating a place to publish them.
Drive to give back
For a long time now, I've been longing to scratch my creative itch with something more than strict coding. I also felt the need to contribute back to the community. I've consumed countless videos, scoured through thousands of stack overflow threads (before AI exodus) and read hundreds of blog posts. All of that was made possible by passionate people wanting to share their experience, thoughts and opinions freely on the internet. So here comes my attempt to pay back.
Simpler is better
I need a place to put any and all of my writings. I've bought the domain but now what? A quick search brings up a ton of "helpful" platforms to create blogs on, obviously sprinkled with the much needed AI assistance at every step. What bothers me the most with these kind of solutions however, is vendor lock-in. I can't give up my work to some profit-driven company without much guarantee that in the future, once (inevitably) the shareholders move to next best thing, my work won't be lost.
I need to be in full control of the content I produce. Every document has to be created locally, with full editorial freedom, without reliance on specific tools. It would also be nice if the format was nice to work with. There's only really one solution to this: plaintext. Every text editor can work with it and it can be easily managed by source control. I'm going to cheat a little bit and allow for Markdown formatting. Even though it's not strictly plaintext, the formatting is human readable. And this will allow for a little bit of fanciness later on, like creating links between articles, or embedding images or code blocks.
Splitting hairs
I've convinced myself (and hopefully you as well) that plaintext with light markdown formatting is the best way of creating and managing written articles. However, I set off to share my creations. Following the 'simpler is better' mindset, I think that pure HTML will be best for my purposes. Markdown maps 1:1 to HTML tags so even manual conversion is doable. And for this first article it's exactly what I'm intending to do: write the text in markdown and convert it to HTML by hand, tag-by-tag. This, in my opinion, is a crucial step before doing any automation. Figuring out what are the steps, what can and need to be automated and, most importantly, what is the expected outcome is often overlooked. I'm guilty of it myself very often: programmers often spend hours even days automatic tasks that take minutes to do manually.
Here, similarly to markdown extension to plaintext, I will allow myself to cheat. Pure HTML, is... ugly. I will write some CSS and even JS to make the website function and look modern. However, and this is important: the core is still pure HTML. This way I'm hoping to achieve more than just have full control over the content. I strive to make my creations accessible to everyone. I don't want to bog down someones mobile connection by downloading tons of react frameworks whenever they visit my website. Even if they are using `curl` to fetch pure data, I want it to be readable. Moreover, I hope that by crafting the documents correctly, they will be easily readable by people with disabilities. Screen readers should pick up on the standard layout and allow for navigation. "Reading mode" of the browser (that I myself use quite often) should be able to display contents correctly.