I Spent Two Years Thinking About This Blog
Saying I "thought about it" isn't quite right; it was closer to an obsession. It started back when I couldn't write frontend or backend code, couldn't write embedded code either. I was messing around with electronics then, and I stumbled onto @ushio's videos on and their website, and thought it was so much fun that I wanted one too. Over the next six months or so I learned C from scratch, plus a little JS and CSS, and put up a static blog with Hexo deployed on Github Pages — my own little corner of the world, at last.


Later, I came across @Innei’s personal site. Its design was exquisite and it was packed with features; one look was all it took for me to want it, and I even sponsored the project. Although I never ended up using it, I don’t regret spending the money, because it gave me the chance to get my hands on the React source code. Just like when I first encountered C, I thought: it’s only code—what’s the big deal? Someday, I’ll write one myself.

That was in 2024, and then ’24, ’25, and ’26 brought us to where we are now
There’s been no stopping it since then.
Out of Control
It started as nothing more than wanting to add a light/dark toggle to @colmugx's Hexo theme Nlvi. I slapped one together out of Dark Reader's JS -- ugly, and I wasn't happy with it. Then I learned CSS @media, then JS SPA switching, then TailwindCSS's .dark class, then SSR next-theme, and finally a Cookie plus a Head Sync inline script to kill the FOUC flicker. Four or five approaches, all told.

But that was only the tip of the iceberg. After discovering React, I went from the Stone Age of Hexo and plain JavaScript all the way to the Next.js 13 Page Router, then detoured into Vue, studied single-page application routing, learned how the index.html fallback works, and recreated the project countless times. I bought a server and tinkered with Docker, Nginx, and a network-attached storage system; finding 1Panel ugly, I hand-built the Canopy control panel, researched storage arrays and wrote RFS, then got so fed up with acme.sh acting up while I struggled with secure sockets layer certificates in China that I wrote a reverse proxy in Rust: Vane & Lazyacme. It began as eight hundred lines of junk hacked together in three hours one evening, but after some friends in a group chat egged me on, I spent four months cramming in HTTP/3, zero-copy operations, a layered model, and a flow engine. Then there is Seam, a full-stack framework and another enormous rabbit hole—but that story can wait.
Overengineering
Then the age of AI arrived, and my anxiety doubled again.
The most ironic part is that all of this was supposed to be built alongside the blog, documented as it happened. Instead the blog got , the ideas kept piling up, and there was nowhere to record any of them. On one side my conscience kept accusing me: you said you would finish Vane, so you can't stop now. On the other side, a growing sense of helplessness as I drifted further and further away. I always remembered what I was supposed to be doing; I just couldn't get it done. Thinking about it carefully, it has been a very long time since I sat down and wrote anything at all. Looking back now, all of it points to the same thing -- over-engineering.
I honestly didn’t feel I was going off track at the time. Vane? The blog would need to be deployed eventually anyway, so I’d need a reverse proxy. Seam? I’d have to write full-stack code sooner or later, so I might as well build my ideal framework first. Every step had a rationale; every step was something I’d “need later.” But the problem was, “later” would never come, because I never even started...
Failure
A blog doesn’t actually need a reverse proxy or a homegrown framework. But at the time, I treated them as prerequisites—as a justification that seemed reasonable even though it kept blocking me forever. They never were. There was only one real prerequisite: sitting down and writing the first article.
It’s not that I hadn’t worked on the blog. Quite the opposite—I tried three times.

My first attempt was back in the Next.js 13 Page Router days. At the time, I only vaguely understood what a single-page application was and knew nothing about concepts like SSR, SSG, or ISR—but people said SSR was good, so I wanted to use it too. As I kept building, I realized I had no idea what problems these architectures were meant to solve, and I couldn’t continue. Later, I switched to a pure Vue 2 single-page application. Why Vue? Embarrassingly, I just liked the name, and since it was new to me anyway, I figured I’d give it a try. That didn’t last long either. On my third attempt, I returned to React, starting with plain JSX. I learned TypeScript, became comfortable with TSX, understood the difference between CJS and ESM, fell in love with reactive programming, and adopted libraries such as Lucide, Framer Motion, and Radix UI that I would later find indispensable—this time, it finally looked respectable. But I still failed, because fundamentally I was only imitating others: whatever they used, I used too. It looked convincing, but I had no real understanding of why things should be done that way. Add AI hallucinations to the mix, and I could get plenty of things running as a minimum viable product, but they became minefields when it was time to scale up.

Later, I learned about React (Remix) Router loaders, the Next.js 15 App Router, and RSC, but by then daily life had grown so busy that I had little time to code—and thus no chance to fail a fourth time. Looking back, I worked on my site from Next.js 13 all the way through Next.js 15; I had barely finished migrating and hadn’t even launched it when Next.js 16 beta 1 came out.
Let Go
To say I’d “let it go” isn’t quite accurate; I was just tired.

The pace of the AI era is too fast. Models iterate one after another, new techniques surface wave after wave, and I grew more and more anxious, as if stopping meant being overtaken. At the wildest point I wrote code sixteen hours a day and could burn $1.9k USD of tokens in a single day (around February, I think); I was nearly wrecked. But what stopped all of it wasn't some epiphany, just plain exhaustion. Under a rhythm that kept tightening, the last straw came down and instead I felt relief, I let it go, I ; and this way is pretty good too.
I started letting go. I gave up the things I had once clung to, learned when to stop, and left tomorrow’s problems for tomorrow. Vane isn’t finished? Leave it for now. Seam still has a long way to go? Come back to it later. The blog isn’t perfect? Launch it first. I went all in on Vibe Coding: if there’s no problem, leave it alone; if one comes up, deal with it then.
The strange thing is that quality didn't get worse after I let go. I think it's probably because those days of coding weren't wasted. I started using AI back in the GPT-2 days, but at that time I was still dutifully writing every line of code and understanding every concept. That period gave me my foundation. What came later was less Vibe Coding than Context Coding — the judgment I needed was still there, and letting go didn't lead to any stupid mistakes, or accidents for that matter.
All that tinkering before is what gave me the confidence to let go now.
Origin
The final solution turned out to be surprisingly simple: everything on Cloudflare. R2 for object storage, D1 as the edge database, KV for caching, and Worker for server-side rendering—all serverless, with no servers.

Is this answer ironic? Extremely so. Before reaching this “simple” destination, I took one enormous detour. I once planned to self-host, which meant managing a server, wrestling with Docker, and managing containers. So I wrote Canopy as a control panel, Lazycert to manage certificates, Vane as a reverse proxy, and Twig for resource-monitoring instrumentation. A whole pile of projects, all to serve one garbage server.
Storage was the same story. I thought object storage was too expensive and wanted to use my own server’s hard drive, so I wrote RFS, a VFS that atomically deduplicated and consolidated data into a single file. I even revived the registry concept from the 1980s and 1990s, then mounted the whole thing through FUSE. The result? I spent even more time reinventing an inferior wheel while the server sat idle for a year—a thoroughly money-losing venture.

After one long detour, I ended up back at serverless after all. Vercel’s concept is good, but I don’t like Next.js; Vercel also relies on too much magic, and its middleware design—precompiling it to run at the edge—still leaves the system fragmented in the end and has even led to several CVEs. You might as well run everything together at the origin. Cloudflare Workers, on the other hand, is excellent: it takes things to another extreme by compiling artifacts under 10 MB to WASM, allowing real business logic to run at the edge. That’s exactly what I want. Its only drawback is the cost—but that hardly counts as a drawback, since time saved is money.
Less is more
I’d heard this countless times, but it took me two years to truly understand what it meant.
Back to the essence of engineering: “Make it function, make it correct, then make it exceptional.” I finally got on the right track and got it working. Is the blog bare-bones right now? It is. Incomplete? Absolutely. But it’s better than nothing. If you haven’t even put anything online and keep building the thing you “might need,” forever chasing an invisible perfection, you’ll end up with nothing to show for it. This isn’t a compromise; it’s an engineering trade-off. Anyway, I’ve learned to let go. So I let go. Once I stopped obsessing over a single detail, I actually walked out the door. My phone’s camera roll hadn’t seen an outdoor photo in ages, so I took a quick shot by the roadside—I really hadn’t been out in a long time (

Looking back at the detours I took, do I regret them? No. Some things may never make sense until you try them yourself. Besides, in the age of AI, it is virtually impossible to follow the same old path I once did; too many workflows have changed. Then there is this project, Taki, coded entirely with AI—but that does not mean it cannot be maintained for the long term or that it lacks a human touch. Whether AI was involved is not really important anyway. What I enjoy is not writing code itself, but building something...