{
  "title": "Why I Rebuilt My Tech Blog for Blazing Speed",
  "description": "From Next.js to Astro. A deep dive into the technical selection, the development process with AI agents, and my vision for this blog.",
  "locale": "en",
  "slug": "about-this-blog",
  "url": "https://engineer-blog.tomoki-ttttt.workers.dev/en/articles/about-this-blog/",
  "publishedAt": "2026-05-11T15:30:00.000Z",
  "updatedAt": "2026-05-13T15:00:00.000Z",
  "tags": [
    "Astro",
    "Cloudflare",
    "TechBlog",
    "IndieDev"
  ],
  "projectIds": [],
  "markdown": "## Why I Rebuilt My Tech Blog for Blazing Speed\n\nThis blog, **\"Tomokichi's Engineering Log,\"** is a place where I document my learning, development, failures, and improvements as an engineer.\n\nActually, this isn't a brand-new start. This blog originally existed as a Next.js site. However, I decided to overhaul it completely, starting from the tech stack. This wasn't a random whim, but a result of \"lessons learned\" through my experience in indie development.\n\n### Why the Rebuild Was Necessary Now\nThe main reason was that my previous blog had become \"over-engineered\" for its purpose, losing sight of what a technical blog should be.\n\n*   **Excessive Features & Effects**: The previous version relied heavily on animations for visual impact. However, for readers looking for information, these became mere noise. I realized a tech blog should, first and foremost, deliver content instantly.\n*   **Increasing Maintenance Overhead**: With constant updates and security patches required for React Server Components (RSC), I found myself spending more time maintaining the system than writing articles.\n*   **Questioning \"Right Tool for the Job\"**: Next.js is a powerhouse for web apps. But for a static blog with no DB, no Auth, and moderate updates, did I really need such a massive framework? This rebuild is my answer to that question.\n\nDrawing from my experience managing SEO for travel blogs and building full-stack apps like **Tabidea** (an AI travel planner), I redefined what I truly needed: a high-performance space to organize and share my thoughts.\n\n## Behind the Tech Stack: Why Astro?\n\nI explored several modern alternatives, but ultimately settled on **Astro**. Getting here involved some internal debate.\n\n### Other Frameworks Considered\n*   **Vite + React**: The development experience is incredibly snappy. However, when considering the manual effort of handling Markdown parsing, RSS feeds, sitemaps, and content management, Astro’s specialized content-centric features offered a clear advantage.\n*   **Remix / TanStack (Router/Start)**: I love the \"Web Standards\" approach and type-safe routing. But for a site without form actions or dynamic data fetching, these felt like overkill.\n*   **Vue (Nuxt) / SvelteKit**: Excellent ecosystems, but to maximize development speed by leveraging my existing React/TypeScript expertise, I decided to stick with the tools I know best.\n\n### The Deciding Factor: Island Architecture\nAstro is built for content-heavy sites. Its ability to convert Markdown into pure HTML at build time—shipping zero unnecessary JavaScript to the client—was a perfect match. \n\nIn particular, **Astro Content Collections** provides a type-safe environment for managing articles, which acts as a powerful \"guardrail\" when developing alongside AI agents.\n\n## Technical Architecture & Design Philosophy\n\nTo ensure long-term, low-maintenance, and high-speed operation, I kept the stack simple and modern:\n\n*   **Core**: Astro (Intentional exclusion of React/MDX for the blog body)\n*   **Styling**: Tailwind CSS v4\n*   **Tooling**: TypeScript, Biome, pnpm\n*   **Infrastructure**: Cloudflare Workers Static Assets + GitHub Actions\n\n### A Commitment to \"Static First\"\nMy priority is ensuring the site is readable with just static HTML and CSS.\n*   Article bodies are fully converted to HTML during the build process, making them accessible even in JS-disabled environments.\n*   I minimize client-side hydration to keep Lighthouse scores near 100 at all times.\n*   For internationalization (i18n), I avoided complex libraries in favor of a clean, directory-based design.\n\n## Co-creating with AI Agents\nA unique aspect of this rebuild is the development process. I now develop with coding agents like Claude Code and Gemini CLI as my constant partners.\n\nIn an era where we delegate implementation to AI, it’s crucial for the human developer to articulate **\"Design Philosophy and Constraints.\"**\n\nI explicitly set these constraints for this project:\n1.  **\"No React in the content layer.\"**\n2.  **\"No client-side dynamic rendering for articles.\"**\n3.  **\"No unnecessary external scripts.\"**\n\nBy hardcoding these constraints into my prompts and documentation, I prevent the AI from over-complicating the architecture. AI speeds up the implementation, but the human's role is to protect the \"purity\" of the site.\n\n## Why I Publish in Both Japanese and English\nThis blog features an English version under the `/en/` path. This is about more than just reach.\n\nThe primary source of technical information is almost always English. Being able to explain my thoughts and implementations in English is not just about career options—it’s about sharpening my own clarity of thought. Translating my Japanese thoughts into English is a core part of my growth as an engineer.\n\n## What to Expect Moving Forward\n\nI don't intend to just post \"perfect\" answers here. Instead, I want to document the messy, real-world trial and error of modern development:\n\n*   **Indie Dev Strategy**: Decision-making and technical debt battles from projects like Tabidea.\n*   **Collaborating with AI**: Practical methods for prompting, reviewing, and building products with AI.\n*   **Infra & Ops**: Tips for building robust, low-cost systems using Cloud Run, Cloudflare, etc.\n*   **Frontend UX**: Balancing \"usability\" and \"speed\" without just following trends.\n*   **Security & Maintenance**: Best practices for Auth and secret management in small-scale projects.\n\n## Closing Thoughts\nThis blog is the result of pausing to ask, \"What tools do I actually need?\" \n\nI'm not aiming to build a massive media outlet from day one. I want to quietly but passionately stack up the small wins and painful failures I encounter. I hope that when I look back in a few years, I’ll see a clear line representing my growth as an engineer.\n\nFast, light, and readable.\nWelcome to the new \"Tomokichi's Engineering Log.\""
}