Decoupled Mind

As I mentioned before, I wanted my site to be built entirely from Markdown files. It’s not that I’ve fallen out of love with programming, it’s that I’ve got exhausted by the weekly cycle of updates. My focus was slowly shifting toward the “quality of the product” rather than the content itself, content I never actually developed enough. Every project ended the same way: I’d delete the droplet and kill the domain.

If we compare this to everyday life, what I was doing was like buying high-end professional gear for a marathon while actually just taking a light afternoon walk in the shade. In this sense, the “afternoon walk” is the daily act of writing about what’s happening, nothing excessive, nothing demanding, just a few paragraphs like I’m telling anyone who asks what I’ve been working on. I just wanted to translate all of that into a written form instead of letting it stay untold. And if you’re wondering why I feel the need to write about what I’m doing well... why do you feel the need to read about what others are writing?

The idea of the site turning into one big wall of text felt like too much for me as well. Knowing myself, I didn’t want it to be just paragraphs. I still wanted it to feel lively and interactive, something that’s comfortable to look at. Since I work with photography and music, it made sense to have albums for images or audio, a way to group things while still being able to show each item on its own. Whatever I needed, I wanted to avoid using native HTML inside my Markdown. That would break my writing flow.

I achieved this using MkDocs and the Markdown Custom Blocks plugin. They’re easy to set up and even easier to plug into a project. Together, they give you a simple structure, usually just six or seven files, which you can expand as needed. I’ll leave the significance of those two magic numbers as an exercise for the reader. hehe

Another thing I like is the build step that turns everything into static HTML. There’s no heavy JavaScript involved. The content is there immediately, with no loading spinner and no waiting for a framework to hydrate everything. Anyone working in frontend knows this is one of the reasons teams are going back to server-side rendering, trying to get better performance, even if doing it properly isn’t exactly cheap or simple.

Within my 2026 goals was a plan to stop overcomplicating things. My Obsidian vault is where I think and the system I built around MkDocs is where that thinking becomes public. The goal was simple: make it easier to write and publish regularly. That’s why I developed a custom theme I named Quartz, which adds the components that give the content its structure. My website doesn’t need a bunch of components since the default theme layout already covers most of it. Every component you see on the Home page is a custom block. Each custom block uses the ::: syntax and wraps its own HTML, CSS, and JavaScript. For the first time in years, I’m using JavaScript for its intended purpose: adding discrete interactivity to the browser rather than forcing it to carry the weight of the entire site.

Moving to Markdown is a way to protect against platforms becoming outdated or harder to use over time. By separating content from the deployment layer, I’ve removed the risk of vendor lock-in. I have the files, the history (on Git) and the raw source. If I decide to replace Quartz with something else tomorrow, the migration cost is close to zero.