Markdown ist der unsichtbare Klebstoff des modernen Webs. Ob Dokumentation, Notizen in Obsidian oder die Kommunikation mit LLMs – kaum ein Entwickler kommt an der Auszeichnungssprache vorbei. Für viele ist sie die perfekte Lösung: minimalistisch, gut lesbar und leicht zu erlernen. Doch dieser Ruf trügt. Wie der YouTuber Theo (t3.gg) in einer kürzlich veröffentlichten und viel diskutierten Analyse aufzeigt, ist Markdown fundamental kaputt – und je weiter wir es pushen, desto mehr beißt es uns.
Der Zauber der Einfachheit
Es ist wichtig, das Gute an Markdown anzuerkennen. John Gruber und Aaron Swartz erschaffen etwas Magisches: eine einfache Möglichkeit, Text zu schreiben, der sich direkt in HTML übersetzen ließ. Für Entwickler, die sich mit dem Frust von LaTeX in der Uni herumgeschlagen hatten, war Markdown eine Erlösung. Die Lernkurve ist nicht vorhanden, ein Blick auf ein Cheat-Sheet genügt. Der plain text ist fast so lesbar wie das gerenderte Ergebnis. Doch genau diese Ursprünglichkeit – das Design für triviale Dokumente – ist das Kernproblem. Markdown wurde nie dafür gebaut, das zu leisten, was wir heute von ihm verlangen.
Das Problem der Mehrdeutigkeit
Ein Markup-Tool muss eindeutig sein. Markdown ist es nicht. Die Sprache leidet unter einem massiven Feature-Creep, der aus unklaren Spezifikationen resultiert. Es gibt oft zwei oder mehr Syntax-Wege, um exakt dasselbe Output zu generieren. Ob nun **fett** oder __fett__, ATX-Headers (#) versus Setext-Header (Unterstriche), unterschiedliche Listen-Syntaxen oder horizontale Linien, die mit Headern kollidieren – die Mehrdeutigkeit ist überall. Selbst CommonMark, die lobenswerte Initiative, die Sprache zu standardisieren, kann die fundamentale Unschärfe des Designs nicht vollständig beheben. Die Spezifikation mag eindeutig sein, die Sprache selbst bleibt es nicht.
Parser-Hölle und Sicherheitsdesaster
Diese Mehrdeutigkeit führt zu einem Albtraum für Parser-Entwickler. Sobald man verschachtelte Formate wie *fett und **gleichzeitig kursiv*** versucht, öffnet sich die Büchse der Pandora. Das Resultat sind absurde Edge-Cases, die zu einer ganzen Klasse von Sicherheitslücken führen: ReDoS (Regular Expression Denial of Service). Ein simplischer String mit zu vielen Sternchen in einem Link kann einen Parser in eine Endlosschleife zwingen (wie ein bekannter CVE mit Schweregrad 6.9 beweist). Wenn schon einfache Formatierung den Parser überlastet, wie soll das in einer Änderung funktionieren, in der KI-Agenten massenhaft Markdown generieren und parsen?
Noch fataler ist das eingelassene HTML. Die Idee, Inline-HTML in Markdown zu erlauben, war ein fataler Designfehler, vergleichbar mit dem Einbau von Assembler in eine hochabstrakte, sandboxed Umgebung. Um einen Markdown-Parser zu bauen, muss man faktisch auch einen HTML-Parser mitliefern. Sobald Entwickler komplexere Anforderungen haben – LaTeX, Mermaid-Diagramme, Iframes oder verschachtelte Links um Bilder –, greifen sie zu Inline-HTML. Das bricht nicht nur mit der Prämisse der Einfachheit, sondern reißt massive Sicherheitslücken auf. Cross-Site Scripting (XSS) ist in Markdown-Renderern an der Tagesordnung, und die zunehmende Zahl an schnell zusammengehackten AI-Parsern verschärft das Problem nur.
Das C++ der Auszeichnungssprachen
Wir nutzen Markdown wie ein Schweizer Taschenmesser, versuchen aber damit, ein Haus zu bauen. Wir wollen TikZ, PlantUML, custom shortcodes, Footnotes und BibTeX – alles an den einfachen Kern angebaut. Das Urteil des Original-Artikels, den Theo zitiert, trifft den Nagel auf den Kopf: Markdown ist das C++ der Markup-Sprachen. Es ist mit Legacy-Entscheidungen aus den 2000er Jahren (Usenet- und E-Mail-Konventionen) belastet, die heute keinen Sinn mehr ergeben, aber aus Kompatibilität erhalten bleiben müssen.
Fazit: Wir brauchen neue Primitive
Warum also nutzen wir Markdown noch? Weil es da ist und der Wechsel schmerzt. Doch insbesondere im Zeitalter von LLMs und autonomen Agenten, die Markdown als Kommunikationsprotokoll nutzen, wird die Mehrdeutigkeit zum Flaschenhals. Markdown mag als schnelles Format für Blogposts und Notizen weiterhin überleben. Als primitive Schicht für Speicher (Memory) von KI-Systemen oder komplexe Dokumentation ist es jedoch das falsche Werkzeug. Wir brauchen ein neues, eindeutiges Format, das die Klarheit von JSON mit der Lesbarkeit von Markdown verbindet – ohne den Legacy-Ballast und die XSS-Fallen. Bis es soweit ist, werden wir weiterhin unseren Text mit Sternchen und Unterstrichen kämpfen lassen.
Quelle: Theo (t3.gg)
