It’s been about 5–6 years since I started programming at a relaxed pace. When I first encountered the command line, I didn’t even know what it was and remember wondering, “Who would ever use this?” But now, I can’t go a day without having Bash open.

Lately, I’ve been reflecting on something: modern websites feel unnecessarily heavy. It made me curious—if you strip down a site to its essentials, just how small and efficient could it be? This thought led me to revisit the idea of creating a personal blog, one designed to serve as both a diary and a writing platform, but with minimalism at its core.

The main driver behind this project is simple: writing. Writing is undeniably one of humanity’s most powerful communication tools. And if, as Paul Graham predicts, the number of people who can write well will dwindle in the near future, then perhaps there’s value in documenting just how far behind I am compared to machines. After all, it’s not a bad idea to leave a record of your own efforts.

The Paradox of Static Websites

“Less is more.” This famous phrase from the titan of architecture resonates deeply, not just in design but also in the philosophy of Unix. Across all domains, less is never inherently bad. If anything, it can represent a well-contained microcosm.

However, modern websites have become increasingly complex. This complexity stems from the rapid pace of technological evolution and the push to accommodate ever-expanding use cases. But the result is bloated websites, burdened with unnecessary features and weight. In truth, most websites would function perfectly fine as collections of static HTML files, a CSS file or two, and maybe a touch of JavaScript.

Contrary to popular belief, creating an overly large and complex site isn’t a mark of expertise. A website so simple that its structure could fit on a napkin eliminates unnecessary computation, data transfer, and hosting costs. So, why does this complexity persist? It exists, in part, because the more convoluted the web becomes, the easier it is to confine regular users to platforms like social media and blogging services.

The Vicious Cycle of Complexity

This vicious cycle of complexity is evident across industries. It exists at a macro level, though rarely by deliberate intent. Instead, it’s often the unintended consequence of rapid industry growth and the relentless pursuit of knowledge. When the expertise necessary to navigate this complexity is lacking, a simple system to deliver accurate information quickly is all that’s truly needed.

The way to distinguish between intentional and unintentional complexity is straightforward: if simple tasks can no longer be done easily, it’s a clear sign of obstruction and industry stagnation.

To navigate around this, I focus on learning from knowledge that predates these barriers. While this approach may seem like taking the long way around, most foundational knowledge has been built upon countless predecessors and won’t disappear with minor upheavals.

That said, the process of learning can easily grow overwhelming. Therefore, when creating something, I highly recommend drafting a specification document. It’s a simple yet powerful tool to clarify goals and avoid unnecessary complexity.

Specifications Are 90% of the Work

It’s common to lose sight of your goals while working on a project. That’s why writing a specification document should be taken seriously—or at least, it used to be. Today, we live in an era where information can be easily shared and updated. For this reason, I believe specs should function more like a freeform notebook—flexible, open, and editable by anyone at any time.

For my blog, I used Google Keep for authoring. I jotted down as many ideas as possible, similar to using a kind of Pomodoro timer. Whether on a train or at home, I’d revisit what I wrote after some time had passed.

The difficulty with specifications is the inevitable stagnation while writing. However, time is a natural solution to this problem. Start by writing anything down, then refine it through iteration. Once I was satisfied with my spec, I began coding. Compromise is inevitable, but I made sure to establish the non-negotiables: for me, minimalism and responsive design were essential.

Balancing Design and Minimalism

To achieve minimalism, I pared down both HTML and CSS. At the same time, I aimed to implement the bare minimum for responsive design. By “bare minimum,” I mean avoiding pre-made CSS templates. Handwritten CSS was a must. After much deliberation, I settled on the following approach:

@media (max-width: 42em) {
  /* Restricted styles */
}

This simple method overrides CSS based on screen size. However, it’s prone to breaking due to minor mistakes, so I had to keep the CSS as clean as possible.

Initially, I planned to create a simple SSG (static site generator) using a Rust parser. However, I eventually switched to Zola. The reasons were numerous: Zola supports not only standard websites but also landing pages and knowledge bases. It made implementing features like RSS feeds, search functionality, and multilingual support far easier.

The Charm of Micro Features

Multilingual support is one of the few features that must be planned from the very beginning of site development. Besides this, there are only a handful of other features that require early consideration, such as search functionality, RSS feeds, image compression, and tagging. Most other features can be added later.

These micro features don’t determine the quality of a website but do enhance the reader’s quality of life. Below is a list of features I’ve implemented or plan to implement: