Why Are We Still Using Markdown?

The author opens with a tongue‑in‑cheek claim that HTML is the best programming language, setting up a discussion about the true nature of Markdown as a minimal markup language rather than a full‑blown programming language.

Markdown (specifically CommonMark) is praised for its simplicity: its task is merely to convert a Markdown file into HTML, its syntax is clear and readable, and beginners can start by looking at a quick reference table. An example shows how a short Markdown snippet ( # Hello, *I am an*, __Unambiguous__, > Grammar) is rendered into the expected HTML tags.

The author then points out several drawbacks. The language’s goals are vague—users are unsure whether they want UI features or a programming language—leading to feature creep. Multiple syntactic forms for bold and italic (e.g., **bold**, __bold__, <b>bold</b>) coexist, and even more obscure combinations ( _*bold*_, *_bold_*, etc.) produce identical output, creating a "spectacle of ambiguity." This ambiguity has security consequences: the parser markdown-it suffers a ReDoS vulnerability (CVSS 6.9) that exploits these ambiguous patterns.

Inline HTML further aggravates the problem. The author lists several recent CVE entries (CVE‑2025‑24981, CVE‑2025‑46734, CVE‑2025‑7969, CVE‑2025‑60312) that stem from allowing raw HTML, inline plugins, or short‑code execution, expanding the attack surface and leading to recurring XSS issues across many Markdown implementations.

Beyond security, the syntax itself is historically bloated. Markdown supports two heading styles (ATX and Setext), multiple ways to write bold/italic, several list syntaxes, and footnotes that upgrade the grammar from context‑free (CFG) to context‑sensitive (CSG). The author illustrates this with a table mapping requirements (e.g., footnotes, custom blocks, math formulas) to their technical impact (CFG → CSG, need for custom CSS, dependency graphs, etc.).

The difficulty of rendering is highlighted: a simple transliterator that maps **bold** to <b>bold</b> is insufficient when modern Markdown must also handle footnotes, custom blocks, and other extensions. The author likens the modern parser to a full compiler, requiring multiple compilation stages and custom hooks.

Proposed solutions include abandoning inline HTML, defining clear short‑code semantics, and allowing custom hooks at pre‑, mid‑, and post‑compilation stages. The author argues that a well‑defined build system with unambiguous syntax would resolve many of the cited problems, and suggests that none of the existing alternatives (plain text, MDX, ReStructuredText) fully satisfy the requirements.

Finally, the article frames the discussion in formal language theory. It distinguishes markup languages from programming languages, cites Chomsky’s hierarchy (regular, context‑free, context‑sensitive, recursively enumerable), and defines Turing‑completeness. Code examples illustrate a Turing‑complete function versus a non‑computable busy‑beaver placeholder, emphasizing how seemingly small language features can dramatically increase expressive power and complexity.