I'm going off MDX for blogging

This blog uses the MDX file format as the source code for the blog posts.

Here is an example code snippet, for this very page (how meta):

1---
2meta:
3  title: I'm going off MDX for blogging
4  description: I like standardised formats like markdown. MDX allows markdown, plus sprinkle in some React. However, I'm considering that maybe I'd be better off just using React.
5  dateCreated: 2025-05-23
6
7series: 
8    name: remix_blog
9    description: Creating a blog with Remix
10    part: 1
11
12tags: 
13  - "react"
14  - "blogging"
15
16---
17import { GithubPermalinkRsc, GithubIssueLinkRsc } from "react-github-permalink/dist/rsc";
18
19This blog uses the [MDX file format](https://mdxjs.com/) as the source code for the blog posts. 
20
21Here is an example code snippet, for this very page (how meta): 
22
23<GithubPermalinkRsc permalink="https://github.com/dwjohnston/blacksheepcode/blob/120b1419cfc03093baa90531a83e08919b0143b8/src/routes/posts/im_going_off_mdx_for_blogging.mdx#L1-L31">
24
25At build time, the MDX files then go through a series of transformations. 
26
27- The front matter YAML is extracted to JSON files, and these are used to populate the 'view posts by tag' and 'this post is part a series' functionality. 
28- The MDX itself is compiled into regular React JavaScript. 
29
30## The rationale for using MDX
31
32The rationale for using MSX is really that I want to use Markdown, but it's nice to be able to put a React component in here and there. 

At build time, the MDX files then go through a series of transformations.

• The front matter YAML is extracted to JSON files, and these are used to populate the 'view posts by tag' and 'this post is part a series' functionality.
• The MDX itself is compiled into regular React JavaScript.

The rationale for using MDX

The rationale for using MSX is really that I want to use Markdown, but it's nice to be able to put a React component in here and there.

The rationale for using Markdown

I'm a fan of open standards. I'm also a big fan of JSON Schema and OpenAPI.

The main reason is that if you're using an open standard, then you now get a whole wealth of compatable tooling for free.

For example with Markdown we have remark and all of its associated plugins.

Not only do these standard formats allow us to transform the given structure data into something useful, but it also serves as a target for other tools to transform to.

Two entirely seperate tools can thus be compatable by having the standard format as common interchange.

What I'm not liking about MDX - lack of language support in VSCode

Some improvements can be had with the experience by adding the vscode-mdx plugin.

However, I still have these problems:

1. Lack of autocompletion

The plugin does not current support TypeScript, and so properties of a component will no have autocomplete suggestions.

2. Lack of type checking in my IDE.

Similarly, if I missed some mandatory properties, I will not see errors in my IDE. If I reference components that don't exist I will not see errors in my IDE.

3. Lack of type enforcement in my front matter YAML.

The YAML in my front matter has reference to specifc magic strings (eg, tag names, series names).

These are typed freehand, whereas with full typescript support they I could get the autocomplete making it much easier to write them, and not make mistakes.

Conclusions

All this makes me consider whether I'm really getting good value out of MDX.

Especially as I start to add more and more React components, I have to question whether it's much more of a hassle to just be writing straight HTML/JSX.

What do you think, if you're using MDX, are you having these same problems?