Why I reach for MDX for writing (and you should too)

I've written blog posts as HTML, as Markdown, and as JSON that a CMS turns into HTML. MDX is the one that sticks. It's Markdown with a superpower: JSX. When your prose needs a code block, a table, or a custom component, you just write it.

Metadata without a plugin

Most Markdown setups need a frontmatter plugin. With @next/mdx, I export metadata like any other JavaScript value:

export const metadata = {
  title: "Why I reach for MDX",
  date: "2026-09-10",
  tags: ["MDX", "Content"],
};

Then a server component imports the file and reads metadata directly — no gray-matter, no parsing step, no hidden magic.

Content stays local

The biggest win for a personal site is that posts live in the repository. No database, no CMS account, no rate limits. To list posts I read the content directory with fs, and to render one I use a dynamic import:

const { default: Post, metadata } = await import(`@/content/blog/${slug}.mdx`);

The build pre-renders every route. Visitors get static HTML; I get versioned, reviewable content.

When MDX is a trap

MDX is not a CMS for non-technical editors. If multiple people need to publish without touching code, you'll want a headless CMS or a rich text editor. For a solo developer who lives in the terminal, it's the closest I've found to just writing.

My rule: if the content gets too interactive, split it — keep the prose in MDX and the interactive widgets as components to drop in between. That balance is why MDX keeps showing up in my toolchain.