Building a Dev Blog in 2026: Why I Chose Astro

I’ve been meaning to start a dev blog for years. Not because I thought the world needed another one, but because writing forces me to actually understand what I’m doing. When I finally sat down to build it, I spent more time picking the framework than writing the first post. Here’s what I looked at, what I ruled out, and why I landed on Astro.

The core requirements were simple: fast output, low maintenance, and a writing experience that gets out of my way. I wanted to own my content in plain markdown files, not export it from some SaaS CMS. And I didn’t want to ship a kilobyte of client-side JavaScript just to render a static blog post.

What I Looked At

I evaluated four options that come up in every “static site generator” conversation in 2026.

Hugo was tempting for pure speed — it’s the fastest builder and the output is genuinely zero-JS. But Go templates age poorly and MDX support is bolted on. Eleventy has a great philosophy but felt like assembling components from a parts bin. Next.js is overkill for a blog; the full React runtime on every page is weight I don’t need.

Why Astro Won

Island Architecture

Astro’s “islands” mental model clicked immediately. Every page is static HTML by default. When you need interactivity — a theme toggle, a search box — you opt in with client:load or client:visible. The rest stays HTML. For a blog, that means zero JavaScript shipped to the reader unless I explicitly need it.

Here’s what a typical Astro component looks like:

---
// src/components/PostCard.astro
import type { CollectionEntry } from 'astro:content';
 
interface Props {
  post: CollectionEntry<'posts'>;
}
 
const { post } = Astro.props;
const { title, description, pubDate, tags } = post.data;
---
 
<article class="rounded-lg border border-border p-6">
  <h2 class="font-heading text-xl">{title}</h2>
  <p class="text-muted mt-2">{description}</p>
  <time>{pubDate.toLocaleDateString()}</time>
</article>

No virtual DOM, no hydration waterfall. The component runs at build time and produces HTML. That’s it.

Content Collections

The content collections API changed how I think about structured content. You define a Zod schema once:

const posts = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/posts' }),
  schema: ({ image }) =>
    z.object({
      title: z.string(),
      pubDate: z.coerce.date(),
      category: z.enum(['article', 'tool', 'guide', 'case-study']),
      tags: z.array(z.string()).default([]),
      featured: z.boolean().default(false),
    }),
});

Every post frontmatter is validated against that schema at build time. Typos in a pubDate, wrong category value, missing required field — all caught before the build outputs a single file. It’s the kind of guardrail that makes refactoring feel safe.

The Stack

After picking Astro, the rest came together quickly. Tailwind v4 for styling, MDX for content, Giscus for comments.

MDX is the right choice for a developer blog. Plain markdown handles 90% of posts, and when you need a custom component — a styled callout, a rating bar, a support prompt — you drop it in like JSX. No shortcodes, no special syntax, just components.

Giscus ties comments to GitHub Discussions, which means no separate comment database to maintain and no privacy-invasive third-party scripts. Readers with a GitHub account can comment. Everyone else can read the discussion.

Tradeoffs

Astro isn’t the right choice for everything, and I want to be honest about where it falls short.

The build time also increases with content volume. A blog with 20 posts builds in seconds; at thousands of posts, incremental builds matter. Astro has made progress here with its content layer API, but it’s worth knowing the limitation before you commit.

What’s Next

Now that the foundation is in place, I want to write about the actual experience of building with these tools. Upcoming topics include Tailwind v4 setup, Pagefind integration for search, and a post on using AI tools for the build itself.

Conclusion

In 2026, the static site generator landscape is mature. Any of the tools I evaluated would have worked. What differentiated Astro for me was the combination of zero-JS-by-default, first-class MDX support, and the content collections API. Together they make it easy to ship fast pages, write freely in markdown, and trust that the build will catch my mistakes before readers see them.

If you’re building a dev blog and the JavaScript frameworks feel like too much overhead, Astro is worth a serious look.