Notes on Rewriting flea

Why Write flea?

I started out wanting a space on the web where I could speak freely, so I thought about creating a personal blog.

After exploring options like Hugo for website generation and GitHub Pages for deployment, and using them for a while, I found them too complicated. I began to think, “Why not create something for myself that’s simple, readable, and fully under my control?” During this process, I discovered Bear Blog. It served me well for some time, but eventually, I started feeling the limitations of what it could offer. That’s when I decided to build my own tool. Even so, Bear Blog’s simplicity and style really inspired me.

Why Design It This Way?

Two years ago, I wrote an initial, feature-rich version with over 500 lines (at the time, I thought it was great, especially since I had never written a script longer than 100 lines). But recently, when I decided to refactor it to make it as “robust” as possible, I was struck by how many problems and edge cases needed attention. This led me to question my original approach: Why was I putting so much effort into such a small tool? To be honest, it’s really just for my own use, and I don’t have the technical skill to create something as powerful as Hugo or Hexo. With this in mind, I decided to strip away everything unnecessary (features I wouldn’t use, like tag system, automatic navigation, external JS imports, etc.) and the robust code, to focus on writing what I called “flea-core.”

I thought that after trimming the code, I’d still end up with something around 300 lines. But to my surprise, the first version ended up being just over 100 lines. This huge gap made me seriously reconsider everything: First, adding even a “small” feature (like a tag system) seems to cause code to bloat quickly. Second, as a self-use script, why should I worry so much about “users”? Why waste time maintaining features I wouldn’t even use myself? Third, why all the abstraction? Whether it's object-oriented programming or modularizing logic, I was adding unnecessary complexity to this script for the sake of “good engineering practices.” This only created additional writing, reading, and management burden for a process that should have been straightforward. It felt a bit like riding a bike in a spacesuit…

After a few tweaks (including a major CSS overhaul, which is why the version number changed from 0.1.x to 0.2.x), flea became the current version, with only 95 lines of code. It doesn’t follow style guides or best practices, but I can confidently say it’s clear, simple, and easy to use.

I’ve thought about adding new features, but every time I wrote something new, I ended up rejecting it. The main reason? It added to the “cognitive load.” I realized that this script shouldn’t have too many features or room for “hacks” or potential future extensions. It should simply be a quiet little tool.

These are the insights I gained while rewriting flea, and I think they will influence my coding style going forward.