# The epic story of Markdown The Vergecast

# The **epic** story of Markdown | The Vergecast ![rw-book-cover](https://img.youtube.com/vi/arjKK7fRtSA/maxresdefault.jpg) 🔗 **Source:** [# The **epic** story of Markdown | The Vergecast](https://www.youtube.com/watch?v=arjKK7fRtSA) > [!note]+ Document Notes > tags: [markdown, plain-text-formatting, web-history, ai-tooling, open-source-conventions] > author: David Pierce > source: The Verge / Vergecast > reference: https://www.youtube.com/watch?v=arjKK7fRtSA > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: The Epic Story of Markdown | The Vergecast >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--the-epic-story-of-markdown) --- ## 📝 Summary - **What happened:** David Pierce hosts John Gruber (Markdown's creator) and Anil Dash (early tech executive and witness to Markdown's rise) on The Vergecast to trace Markdown's origin, adoption arc, and current status as the de facto lingua franca of AI tooling. - **Why it matters:** A single individual's scratch-your-own-itch formatting tool, born from frustration with raw HTML blogging, became a global convention used by billions — embedded in GitHub, Stack Overflow, Obsidian, and now every major LLM pipeline. - **Key stakeholders:** John Gruber (creator, Daring Fireball), Anil Dash (Six Apart / Movable Type ecosystem), Dean Allen (Textile, now deceased), the open-source and AI industries, and everyday writers and developers worldwide. - **Risks and tradeoffs:** Gruber expresses explicit concern about Markdown overreach — exposing the raw syntax to general consumers who would be better served by WYSIWYG interfaces. The proliferation of "flavors" (GitHub Flavored Markdown, CommonMark, etc.) creates fragmentation, yet Gruber argues this is fine because the underlying *conventions* remain consistent. - **Bottom line:** Markdown succeeded not because it was technically superior but because it was designed to be *read* by humans who had never heard of it — a design philosophy that now also makes it ideal for LLMs. That readability-first principle is a durable lesson for anyone building formats, protocols, or specs. --- ## 📖 Main Content ### 🌱 Origins: Scratching a Blogger's Itch John Gruber launched Daring Fireball in August 2002 using Movable Type as his CMS — the dominant blogging platform of the era, predating WordPress. Because he pasted raw HTML into post bodies, he quickly grew frustrated. He had already been running local scripts to convert proto-Markdown to HTML, but round-tripping through HTML for every subsequent edit was painful. Dean Allen's **Textile** (2001–2002) was the closest prior art, and Gruber actively contributed suggestions to Brad Choate's Movable Type port. Allen himself told Gruber, in what Gruber calls a "seminal moment," to stop suggesting changes and just make his own thing. That directive produced Markdown, released in **2004**. ### 🎯 The Overriding Design Goal: Readability Over Writeability Gruber is explicit: the primary design goal was not ease of typing but **readability of the raw source**. His test: print a Markdown document, hand it to someone who has never heard of Markdown, and they should intuitively understand what the asterisks and brackets mean. This differentiates Markdown from Textile and from WYSIWYG HTML editors. He deliberately restricted the syntax to ASCII characters even though typographically richer Unicode characters were easily accessible on a Mac keyboard (e.g., Option-8 for a real bullet). Readability trumped typographical precision. ### 📈 Adoption: Slower Than You Think, Then Unstoppable Contrary to the "overnight success" narrative, Gruber describes 2004–2010 as a **slow, somewhat disappointing plateau**. Two inflection points accelerated adoption: 1. **Stack Overflow (2008):** Even among an audience of developers who could write HTML fluently, Markdown was controversial at launch. It won anyway, and coders became evangelists. 2. **GitHub (~2009–2010):** GitHub made GitHub Flavored Markdown (GFM) the default for READMEs and issues without asking. This forced technical adoption, eliminated the "I can just write HTML" objection through habituation, and turned developers into the format's missionary class. Anil Dash adds important context from the Movable Type side: non-technical bloggers at Gawker, Huffington Post, and similar properties immediately recognized Markdown as "what I would have written in an email anyway" — no mental model shift required. ### 🌍 The Blogsphere Context Both Gruber and Dash emphasize that the early-2000s blogsphere is nearly unimaginable from a 2026 vantage point. RSS readers made it feasible to read *everything* published. Tools like Cameron Marlow's **BlogDex** surfaced popular links across all blogs, functioning as a primitive social graph. The total volume of interesting technical output was small enough that a single developer shipping a formatting tool could achieve global mindshare within the community. Dash draws an explicit parallel to **MCP (Model Context Protocol)** as the closest current analog: an open, interoperable, individually-buildable format standard. ### ⚠️ The Overreach Problem Gruber identifies three phases of his relationship with Markdown: 1. **Frustration (2004–~2010):** Not popular enough. 2. **Satisfaction (~2010–~2020):** Used by the right people in the right contexts. 3. **Alarm (~2020–present):** Exposed to audiences who should have WYSIWYG. His critique of **Obsidian-style "live preview" editors** (and similar tools) is precise: there is a meaningful distinction between (a) a plain-text editor that syntax-colors Markdown, (b) a hybrid that toggles between edit and view modes, and (c) a true WYSIWYG that hides markup entirely. Category (b) reintroduces the exact problem Markdown was designed to solve — the "where does the italics end?" confusion of pre-Markdown WYSIWYG editors — just with asterisks instead of invisible formatting tags. He considers **Apple Notes' Markdown export** (rather than Markdown input) an appropriately scoped use. ### 🤖 Markdown and LLMs Gruber offers a clear mechanistic explanation for why LLMs both consume and emit Markdown well: - LLMs are pattern-matching over a corpus of human-readable text. Markdown was optimized for human readability, so it fits naturally into that corpus. - LLMs can tolerate Markdown's **forgiving error semantics** (an unclosed italic run is harmless) in ways they cannot tolerate JSON's **strict validity requirements** (one malformed character invalidates the entire document). - The lightweight character footprint (just ASCII punctuation) makes Markdown fast and token-efficient to emit. Gruber explicitly did not anticipate this use case — he just wanted a good blogging format. Anil Dash's editorial coda: the fact that an individual blogger's side project became the foundation layer of trillion-dollar AI infrastructure is itself a lesson in who actually shapes technology — and a lesson conspicuously absent from elite computer science curricula. ### 📐 Conventions vs. Specifications One of the most conceptually rich moments: Gruber rejects the framing of Markdown as a formal *specification* or *syntax* and insists it is a **convention** — a set of widely legible agreements about how to decorate plain text. This explains why he has never been bothered by the proliferation of flavors. What he cares about is that the *underlying conventions* (asterisks for bold, underscores for italics, etc.) have now become the default across all variants. He describes winning the "how do you italicize in plain text?" debate — a debate he had strong opinions about since the early 1990s — as his deepest satisfaction. --- ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=0) Introduction — David Pierce sets up Markdown - Markdown defined as "a way of writing text that both a computer and a human can understand" - Called the "lingua franca of the AI industry right now" - `.md` / `.claude.md` files cited as contemporary evidence of ubiquity #### ⏱️ [00:02:30](https://www.youtube.com/watch?v=arjKK7fRtSA&t=150) News break — Fox/Roku, Fable/Anthropic, Honor Magic V6 - Fox acquiring Roku for ~$22B; stated intention to keep Roku as "Switzerland of streaming" - US government attempted to block Anthropic's "Fable" model from foreign nationals; Anthropic complied by shutting it off entirely; Fable described as Mythos with guardrails - Honor Magic V6: thinnest foldable yet, 2-day battery, solid IP rating, $2,000 #### ⏱️ [00:06:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=360) John Gruber — Origin story - CS degree 1996; freelance graphic design; launched Daring Fireball August 2002 on Movable Type - Writing raw HTML into post body fields within a year felt intolerable - Local scripts converting proto-Markdown → HTML were the immediate precursor - Dean Allen's Textile was the inspiration and foil; Allen's direct message ("just make your own thing") was the catalyst #### ⏱️ [00:12:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=720) Readability-first design philosophy - Primary goal: print the raw file, hand to a non-technical person, they understand it - ASCII-only by deliberate choice even though richer characters were available - Readability > writeability as the differentiating principle vs. all prior art - Post-authorship editing frequency justified optimizing for reading, not typing #### ⏱️ [00:17:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1020) Anil Dash — Movable Type / blogsphere context - Movable Type powered Gawker, Huffington Post, and the major blogs of the era - Non-technical writers immediately recognized Markdown as "what I would write in an email" - Textile vs. Markdown: Textile felt like performing being Dean Allen; Markdown felt native - BlogDex (Cameron Marlow) as primitive social graph; RSS as universal feed reader #### ⏱️ [00:24:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1440) Adoption arc — slower than mythology suggests - 2004–2010: slow uptake, Gruber describes as "disappointing" - Stack Overflow (2008): controversial to adopt Markdown even among developers; succeeded - GitHub (~2009): forced GFM as default without asking; turned resistant developers into evangelists through habituation - The "I can write HTML, I don't need this" objection dissolved after sustained use #### ⏱️ [00:32:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1920) Three phases of Gruber's relationship with Markdown - Phase 1: frustration — not popular enough - Phase 2: satisfaction — right users, right contexts - Phase 3: alarm — overexposed to audiences who need WYSIWYG, not raw syntax #### ⏱️ [00:36:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2160) WYSIWYG critique and the "live preview" problem - Pre-Markdown WYSIWYG editors: "where does the italics end?" confusion - Markdown solved this with explicit punctuation: either the asterisk is there or it isn't - Obsidian-style toggle-mode editors reintroduce the same confusion - Apple Notes: export as Markdown is appropriate; Markdown *input* is not - Google Docs Markdown mode: "weird and bad" #### ⏱️ [00:42:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2520) Conventions vs. specifications - Gruber explicitly rejects "spec" framing; Markdown is a *convention* - Proliferation of flavors is fine because conventions are consistent across all of them - Real win: asterisk-for-italics is now the universal plain-text decoration standard - "Let a thousand Markdowns bloom" as explicit philosophy #### ⏱️ [00:47:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2820) Markdown and LLMs - LLMs pattern-match on human-readable text corpora → Markdown fits naturally - Forgiving error semantics (unclosed italic = no problem) vs. JSON strictness (one bad char = invalid file) - LLMs emit Markdown better than JSON for precisely this reason - Lightweight ASCII footprint = token-efficient - Gruber: "I just wanted to blog" — LLM ubiquity was entirely unanticipated - Dash: Sam Altman should send Gruber $100M #### ⏱️ [00:52:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=3120) Closing — individual creation and the history lesson - Dash: the most important lesson is that a trillion-dollar infrastructure layer was made by one guy who writes about Apple - Elite CS programs teach a history of tech in which this fact is invisible - MCP cited as the closest current analog to the early blogsphere's open-format energy - Individual creation of interoperable standards is still possible; the story of Markdown is evidence --- ## 📚 References - [Daring Fireball](https://daringfireball.net) — John Gruber's blog; original home of Markdown - [Markdown 1.0 release post](https://daringfireball.net/projects/markdown/) — Original announcement and spec - [Textism / Dean Allen](https://web.archive.org/web/2004/https://textism.com) — Textile creator; direct inspiration - [Movable Type](https://movabletype.org) — CMS that first integrated Markdown plugins; made by Six Apart - [Stack Overflow](https://stackoverflow.com) — Early major adopter; Markdown support was controversial at launch (2008) - [GitHub Flavored Markdown](https://github.github.com/gfm/) — The flavor that forced developer adoption - [CommonMark](https://commonmark.org) — Effort to standardize Markdown specification - [Obsidian](https://obsidian.md) — Popular Markdown-native note-taking app - [BlogDex — Cameron Marlow](https://web.archive.org/web/2004/http://blogdex.net) — Early link-popularity aggregator for blogs - [Anthropic Claude / "Fable" model](https://anthropic.com) — Referenced in news segment as a Markdown-consuming AI system --- ## 🗣️ Paraphrase - John Gruber built Markdown in 2004 because writing raw HTML into Movable Type's post editor was making him miserable. He had already been running local conversion scripts; Dean Allen's pointed suggestion to stop submitting patches to Textile and build his own thing pushed him over the edge. The one principle he held above all others was that the raw Markdown source should be legible to someone who had never heard of it — italics surrounded by asterisks *look* like emphasis, headers preceded by pound signs *look* like headers. He restricted the syntax to ASCII not because it was technically necessary but because readability demanded it. - Adoption was slow for six years, then violent. Stack Overflow's 2008 decision to support Markdown was internally controversial even among an all-developer user base; GitHub's slightly-later choice to make GFM the default for all repository text bypassed the debate entirely and habituated resistance away. Once developers used Markdown, they stopped wanting to go back. They then evangelized it into every adjacent tool. - Gruber now worries the format has overreached. Consumer-facing apps like Apple Notes, Google Docs, and live-preview editors like Obsidian are exposing Markdown syntax to people who would be better served by invisible WYSIWYG formatting. The same "where does the italics end?" confusion that plagued pre-Markdown WYSIWYG editors reappears in toggle-mode editors that show you the asterisks but also hide them. He considers Apple Notes' *export-to-Markdown* feature appropriate; *input-in-Markdown* as the primary interface is not. - The LLM chapter was entirely unanticipated. Gruber's explanation for why it happened is elegant: LLMs pattern-match over human-readable text, Markdown was designed for human readability, and Markdown's forgiving error semantics mean LLM-generated Markdown with a small mistake is still valid and useful, whereas LLM-generated JSON with a small mistake is broken. The format that was designed to be read by a person with no technical background turns out to be ideal for a machine that learned from text written by people with no technical background. --- ## 📰 Newsletter **Plain Text, Profound Impact: The Markdown Origin Story You Need to Hear** If you've ever typed `**bold**` or `## Heading` in a post editor, a README, or a block of Gutenberg markup, you've used Markdown — and this week's Vergecast episode is the deep-dive origin story behind that deceptively simple format. John Gruber, creator of Markdown *and* the beloved Apple-commentary blog Daring Fireball, joined David Pierce alongside Anil Dash (former Six Apart executive) to trace the format from its 2004 debut — born out of pure frustration with writing raw HTML into Movable Type's post body — to its current status as the invisible backbone of every major AI tool on the planet. A few things worth flagging for WordPress folks specifically: - **Gutenberg and Markdown**: The block editor has had Markdown shortcut support for years (type `##` and hit space; voilà, a heading block). Gruber's "conventions, not spec" framing helps explain why this works seamlessly across editors with totally different codebases. - **Obsidian as a case study**: Gruber is gently critical of live-preview Markdown editors — including Obsidian — for reintroducing the exact WYSIWYG confusion Markdown was designed to eliminate. Worth a discussion in any team that uses Obsidian for internal docs. - **The AI angle**: Every `.claude.md`, `AGENTS.md`, or custom-instruction file you're writing for AI assistants is a Markdown file. Gruber explains precisely *why* LLMs prefer Markdown to JSON — forgiving error semantics, ASCII efficiency, and readability-first design. That's actionable for anyone building AI-integrated WordPress workflows. - **The broader lesson Anil Dash closes with**: The trillion-dollar AI infrastructure layer runs on a format one guy made because he hated writing HTML on his blog. Individual contributors still build foundational things. That's a message worth amplifying in any open-source community. 🎙️ [Listen on The Vergecast](https://www.youtube.com/watch?v=arjKK7fRtSA) | 📝 [Markdown spec — Daring Fireball](https://daringfireball.net/projects/markdown/) --- ## ✅ Action Items #### DevRel - Document the "readability-first" design philosophy as a case study for developer education on format and API design. - Build a short explainer (blog post or video) contrasting Markdown, Textile, and raw HTML for audiences new to plain-text formatting. - Create a quickstart guide for AI-integrated workflows using `.md` instruction files (`.claude.md`, `AGENTS.md`, etc.). #### OSPO - **Policy & Governance:** Review whether internal documentation standards should specify which Markdown flavor is canonical (CommonMark, GFM, etc.) to reduce inter-tool fragmentation. - **Software Inventory:** Audit toolchain for Markdown parsers and flag any that introduce non-standard flavors without disclosure. - **Community Engagement:** Surface Gruber's "let a thousand Markdowns bloom" convention-vs-spec framing in open-source governance discussions where format standardization debates arise. #### Community - **Contributors:** Add a Markdown style guide to onboarding documentation; reference the readability-first principle explicitly. - **Maintainers:** Consider a governance template for format/convention decisions that distinguishes "spec" (enforced, strict) from "convention" (emergent, forgiving). #### WordPress - **Core:** Audit existing Markdown shortcut support in Gutenberg against GFM conventions; document any divergence for contributors. - **Documentation:** Ensure DevHub and HelpHub use consistent Markdown flavor; note which flavor in the style guide. - **Training:** Add a lesson on Markdown history and philosophy to the WordPress developer learning path — Gruber's origin story is an excellent hook. - **Accessibility:** Verify that Markdown-to-HTML conversion in the block editor produces accessible output (proper heading hierarchy, alt text preservation). - **Core AI:** Establish a standard for `.md` instruction files used in AI-assisted WordPress development workflows; publish templates. - **CLI:** Ensure `wp` CLI documentation and scaffold outputs use consistent, documented Markdown flavor. #### The WPCC - **Programs:** Commission a "Markdown in WordPress" historical explainer as a fellowship or microgrant project — connecting open-source history to current contributor practice. - **Projects:** Host a documentation sprint focused on plain-text documentation standards across WordPress projects. ### FAIR - **Technical independence:** Markdown files are format-independent, human-readable, and require no proprietary tooling to parse — this aligns directly with FAIR data provenance principles. Advocate for Markdown as the default for community-generated documentation over proprietary formats. - **Policies and covenants:** The "conventions not spec" model is a useful framing for anti-lock-in clauses in contributor agreements. - **Productized governance artifacts:** Publish a one-page "Markdown flavor decision scorecard" for projects choosing between CommonMark, GFM, and custom extensions. --- ## 🧪 Hypotheses 1. **Readability-first design predicts format longevity:** Formats designed so that raw source is legible to non-technical readers will outlast formats optimized primarily for machine parsing or authoring speed. 2. **Forgiving error semantics accelerate AI adoption:** LLMs will preferentially emit and consume formats where small errors are tolerated over formats where small errors are fatal (e.g., Markdown over JSON), independent of format expressiveness. 3. **Forced habituation is more effective than opt-in adoption for developer tools:** GitHub's mandate of GFM without user input was more effective at driving adoption than Stack Overflow's opt-in introduction, suggesting that platform defaults trump individual preference in format standardization. 4. **Format overreach follows a predictable arc:** Any format designed for a technical niche will face a "overreach crisis" when adopted by mass-consumer surfaces, where the raw syntax becomes a UX liability rather than an asset. 5. **Individual-created open formats concentrate disproportionately in periods of low technical-output volume:** The blogsphere era (early 2000s) enabled individual format creation at scale because total interesting technical output was low; analogous windows may appear at the start of new platform cycles (e.g., early MCP ecosystem). 6. **Convention without enforcement produces higher cross-tool compatibility than enforced specification:** Markdown's flavor proliferation, despite producing incompatibilities at the margins, preserved more cross-tool readability than a strictly enforced spec would have, because conventions self-select for legibility. ### 📊 Methodology - **H1 (readability longevity):** Corpus analysis of format adoption curves (Textile, reStructuredText, AsciiDoc, Markdown) correlated with independently-rated readability scores of raw source files. Longitudinal. - **H2 (forgiving semantics / LLM):** Controlled experiment: instruct identical LLMs to emit Markdown vs. JSON vs. XML for equivalent content; measure error rate and downstream parse success. Compare token count and latency. - **H3 (forced vs. opt-in habituation):** Quasi-experimental comparison of Stack Overflow (opt-in Markdown, 2008) vs. GitHub (forced GFM, ~2009) using adoption rate curves, complaint volume in issue trackers, and longitudinal survey data from developer tool usage studies. - **H4 (overreach arc):** Qualitative case study of 5–8 formats (Markdown, RSS, XML, JSON, YAML) mapping the moment of mass-consumer adoption against UX complaint emergence; identify common triggers. - **H5 (platform cycles and individual creation):** Historical analysis of format creation density per year, mapped against total industry output volume; test whether creation peaks precede volume spikes. - **H6 (convention vs. spec compatibility):** Interoperability test suite across 10+ Markdown parsers; compare cross-parser rendering consistency against equivalent comparison for a strictly specced format (e.g., CommonMark vs. original Markdown). ### ❓ Questions - At what point does a "convention" require a formal spec to prevent fragmentation that harms interoperability more than it helps flexibility? - Is the LLM preference for Markdown over JSON a temporary artifact of training data composition, or a durable property of the format's error semantics? - Could a WYSIWYG editor be designed that produces clean Markdown *output* without ever exposing users to Markdown *syntax* — and would Gruber endorse that as the ideal end state? - What would Markdown look like if it were designed today, with LLM consumption as a primary use case alongside human readability? - Is MCP actually a structural analog to Markdown's early adoption arc, or is the current infrastructure landscape too different for individual-created formats to achieve similar penetration? - How much of Markdown's success is attributable to the ASCII constraint specifically, versus the readability-first philosophy more broadly? ### 🔮 Future Research - **Markdown and accessibility:** Systematic study of whether Markdown-to-HTML pipelines in major CMSes produce WCAG-conformant output by default, and where they fail. - **LLM instruction file conventions:** Emerging research on whether `.claude.md`, `AGENTS.md`, and similar files are converging on shared conventions — and whether that convergence is happening faster or slower than Markdown's original adoption arc. - **Post-Markdown plain-text formats:** Survey of formats attempting to succeed Markdown (MDX, AsciiDoc revival, Typst) and analysis of whether any satisfy Gruber's readability test. - **The "Dean Allen effect":** Influence of deceased or inactive creators on format conventions — how does the ecosystem handle authoritative interpretation when the original author is unavailable? - **Markdown in non-English contexts:** How does the ASCII-only convention interact with non-Latin writing systems? Are there parallel convention wars in other language communities? ### 💡 Implications - **Practice:** Developers and content teams should distinguish between Markdown-as-input (appropriate for technical authors) and Markdown-as-export (appropriate for consumer apps). Conflating them produces bad UX. - **Policy:** Organizations adopting AI tooling should standardize their `.md` instruction file conventions now, before fragmentation sets in — the Stack Overflow / GitHub lesson applies. - **Security:** Markdown parsers with lax sanitization are a known XSS vector; the "forgiving" property that makes Markdown great for LLMs also means parser hardening requires explicit effort. - **Education:** The Markdown origin story is a concrete, teachable example of how open conventions beat proprietary formats — and how individual contributors shape infrastructure. It belongs in CS curricula. - **Funding models:** Gruber received no royalties from Markdown's ubiquity. The open-source funding gap is illustrated starkly here: the format underpinning trillion-dollar AI systems was created by one person who got nothing. This is an argument for retroactive funding mechanisms (OSPO stipends, foundation grants, GitHub Sponsors for foundational projects). --- ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level approximately 10–11 (conversational podcast transcript; accessible vocabulary, complex ideas handled informally). Flesch Reading Ease approximately 60–65 (fairly easy to read). #### 👀 Visual learners - **Present:** None (audio-only transcript). - **Improve:** Timeline graphic of Markdown adoption (2002 → 2004 launch → 2008 Stack Overflow → 2009 GitHub → 2020s AI ubiquity); side-by-side comparison of raw Markdown vs. rendered HTML vs. WYSIWYG editor view; architecture diagram of how LLMs consume and emit Markdown. #### 🔊 Aural learners - **Present:** Full podcast audio available at the YouTube URL; natural conversational format. - **Improve:** Chapter markers in the YouTube video would help navigation; a 2-minute audio summary clip for sharing. #### 🗣️ Verbal learners - **Present:** Rich use of analogy ("Switzerland of streaming," "lingua franca"); definitions embedded conversationally. - **Improve:** Explicit glossary callout for Markdown, WYSIWYG, GFM, CMS, ASCII, LLM, Textile; plain-language sidebar distinguishing "convention" from "specification." #### 🧩 Kinesthetic learners - **Present:** None explicitly. - **Improve:** "Try it yourself" Markdown sandbox (e.g., StackEdit or Dillinger embedded); step-by-step exercise converting an HTML blog post to Markdown; checklist for choosing between Markdown input vs. Markdown export for a given product context. #### 🧠 Logical learners - **Present:** Gruber's causal explanation of LLM/Markdown affinity is well-reasoned; adoption arc is presented with rough timeline. - **Improve:** Decision tree for "should my app use Markdown input or WYSIWYG?"; table comparing Markdown flavors (CommonMark, GFM, original) across key syntax decisions; error-semantics comparison table (Markdown vs. JSON vs. XML). #### 🧑‍🤝‍🧑 Social learners - **Present:** Conversational three-person format naturally models collaborative sense-making. - **Improve:** Discussion prompt set for dev teams ("Which Markdown flavor are we standardizing on, and why?"); community forum thread template for Markdown flavor debates. #### 🧘‍♀️ Solitary learners - **Present:** Rich enough for independent deep reading of the transcript. - **Improve:** Reflection prompts ("What format have you used that was designed for readability? What made it work?"); self-paced companion workbook. #### 🌿 Naturalistic learners - **Present:** Ecosystem language used naturally ("let a thousand Markdowns bloom," format evolution). - **Improve:** Explicit framing of Markdown as an ecosystem with niches (technical docs, AI prompts, consumer notes), predators (proprietary formats), and selection pressures (LLM training data). --- ### 📊 Accessibility Assessment #### Screen reader semantics - **Present:** Transcript is plain text; when rendered as this document, heading hierarchy is correct. - **Improve:** YouTube auto-captions should be reviewed for accuracy on technical terms (e.g., "GFM," "ASCII," "Movable Type," "Anil Dash"). #### Keyboard navigation - **Present:** YouTube player is keyboard-navigable. - **Improve:** Chapter/timestamp links in the video description would reduce navigation burden for keyboard and screen reader users. #### Contrast and readability - **Present:** N/A for audio. - **Improve:** Any companion visual assets should meet 4.5:1 contrast minimum. #### Text resizing and reflow - **Present:** Transcript as text reflows correctly. - **Improve:** Ensure any published companion article is tested at 200% zoom. #### Media and captions - **Present:** Auto-captions present on YouTube. - **Improve:** Human-reviewed captions recommended given high density of proper nouns and technical terms; downloadable transcript link in video description. #### Forms and interactions - **Present:** N/A. #### Standards reference - Caption accuracy gaps map to WCAG 2.2 AA 1.2.2 (Captions — Prerecorded); missing timestamp navigation maps to 2.4.1 (Bypass Blocks). --- ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** Discussion is US/English-centric; Movable Type's global blogsphere impact is noted. - **Improve:** Acknowledge Markdown's interaction with non-ASCII writing systems; note that the ASCII constraint is not culturally neutral globally. #### Inclusive language - **Present:** Conversational, informal; generally gender-neutral. - **Improve:** "A guy can make a thing" (Dash, approximately) is used casually and repeatedly — worth examining whether this framing inadvertently centers male creators in the "individual makes a thing" narrative. #### Neurodiversity support - **Present:** Conversational format is accessible; no dense jargon walls. - **Improve:** The transcript lacks structural markers; a chaptered, structured companion document (like this one) significantly aids neurodivergent readers. #### Representation - **Present:** Two white male guests; host is white male. - **Improve:** Dean Allen (deceased, mentioned but not present) was a significant influence; future episodes on format history could actively seek out underrepresented contributors to the Markdown ecosystem. #### Psychological safety - **Present:** Warm, collegial tone; disagreement (Gruber on Apple Notes) is framed respectfully. - **Improve:** No content warnings needed; the Fox/Roku and Fable/Anthropic news segments are editorially framed but not distressing. --- ### ✅ Logical Validity #### Strong reasoning - **Gruber's LLM/Markdown affinity argument** (approximately 00:47:00): Deductive chain — LLMs pattern-match on human-readable text corpora → Markdown was designed for human readability → Markdown errors are harmless → therefore LLMs prefer Markdown. Each premise is independently defensible and the conclusion follows. Clear and well-supported. - **Readability-over-writeability as differentiator** (approximately 00:12:00): Inductive argument from observed outcomes — every prior art (Textile, WYSIWYG) optimized for something else; Markdown optimized for readability; Markdown won. The counterfactual is not fully explored but the correlation is strong. - **Forced adoption > opt-in adoption** (approximately 00:32:00): Anil Dash's Stack Overflow vs. GitHub comparison is a genuine natural experiment with a clear outcome, though not rigorously controlled. #### Fallacies - **Post hoc ergo propter hoc (approximately 00:24:00):** "GitHub adopted GFM → developers became Markdown evangelists → Markdown became ubiquitous." The causal chain is plausible but not distinguished from concurrent factors (growth of open-source culture, rise of developer blogging, etc.). Fix: acknowledge confounding variables; cite adoption rate data if available. - **Survivorship bias (throughout):** The conversation centers on Markdown's success without systematically examining contemporaneous formats that failed despite similar design philosophies (e.g., reStructuredText, AsciiDoc). This inflates the apparent predictability of Markdown's success. Fix: briefly acknowledge formats with similar properties that did not achieve the same adoption. - **Slippery slope (approximately 00:36:00):** Gruber's "Apple Notes Markdown input is too far" argument implies a clear threshold that is not fully specified. The line between "syntax-colored plain text editor" and "inappropriate consumer exposure" is asserted rather than defined. Fix: articulate specific UX failure modes that mark the threshold. #### Tone of voice - **Warm, nostalgic, collegial.** Example: "I just wanted to blog and have a good format for my writing, really." The tone is self-deprecating from Gruber, enthusiastic and historically contextualizing from Dash, and curiosity-driven from Pierce. Technical depth is delivered conversationally without condescension. One moment of mild irreverence: Dash's "I think Sam Altman should send John $100 million" — signals shared frustration with open-source compensation norms without belaboring it. --- ### 🛡️ DARVO Analysis - **Deny:** No significant denial patterns. Gruber is candid about the slow adoption period and his own disappointment, which is anti-DARVO. - **Attack:** None directed at individuals. Mild criticism of Apple Notes, Google Docs Markdown mode, and Obsidian-style editors — but framed as design critique, not personal attack. - **Reverse victim/offender:** The closest pattern is Dash's framing that John Gruber was never compensated while trillion-dollar companies benefit from his work. This is not DARVO in the pejorative sense — it is a legitimate equity observation — but it does rhetorically recast Gruber as an aggrieved party. Worth noting as a rhetorical move that could be used more manipulatively in other contexts. - **Overall:** No DARVO patterns of concern. The episode is a constructive, retrospective conversation without adversarial dynamics. --- ## 🎯 Conclusion Markdown's story is not primarily a technical story — it is a story about design philosophy. John Gruber made one consequential decision: optimize for the reader of the raw source, not the author or the machine. That decision, made to solve a personal blogging frustration in 2004, produced a format so legible that non-technical bloggers recognized it as "what I would write in an email," that developers became evangelists after forced habituation, and that LLMs, trained on human-readable text, consume and emit better than strictly-valid formats like JSON. The practical takeaways: 1. **Readability-first is a durable design principle.** If the raw artifact is legible without tooling, it will outlast the tools. 2. **Conventions beat specifications in open ecosystems.** Don't fight the flavors; ensure the core conventions hold. 3. **Forgiving error semantics are a feature, not a bug,** especially for AI-generated content. 4. **Know where Markdown belongs.** Technical authors, developer tooling, AI instruction files: yes. Consumer apps where users expect WYSIWYG: export only. 5. **The open-source funding gap is real and unresolved.** The format underpinning today's AI infrastructure was made by one person who got nothing. That is a policy problem, not just a curiosity. --- ## 🔄 Refactor Appendix — The Epic Story of Markdown ### 📚 Literature Atoms #### [H1] Readability-first design predicts cross-context format adoption > [!quote] ID:rw_md001 > "The overriding goal of it is you should be able to print it out in markdown format and hand it to somebody who's never heard of markdown and they can just read it." **Context & use**: - Approximately 00:12:00 into the episode; Gruber explaining core design philosophy - This is the single most transferable principle in the episode — applicable to API design, documentation, CLI output, and AI prompt engineering, not just text formatting **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://md001)  --- #### [H2] Forgiving error semantics make Markdown ideal for LLM emission > [!quote] ID:rw_md002 > "Markdown, if you forget to end an italics run, who gives a crap. Doesn't matter. It's still good. And so LLM's making one little tiny mistake in the markdown they emit, it's still fine." **Context & use**: - Approximately 00:47:00; Gruber explaining LLM/Markdown affinity - Directly actionable for anyone choosing output formats for AI pipelines; explains why Markdown should be preferred over JSON or XML for LLM-generated structured text **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://md002)  --- #### [H3] Markdown's adoption was slow until platform defaults forced habituation > [!quote] ID:rw_md003 > "GitHub kind of did that. It put it in the heads of technical people and then they became the evangelists for it." **Context & use**: - Approximately 00:32:00; Anil Dash and Gruber discussing GitHub's forced-default strategy - Generalizable lesson for any open format or convention seeking developer adoption: voluntary opt-in is slow; platform defaults are fast **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://md003)  --- ### 🧠 Permanent Candidates #### [P1] Formats designed to be read without tooling outlast formats optimized for tooling **Claim** (one sentence, Courtney's voice): A format's long-term adoption is better predicted by the legibility of its raw source to a non-technical reader than by its expressive power or ease of authoring. **Evidence pointer**: [[#H1]] — Gruber's explicit statement that readability was the overriding goal, and the subsequent 20-year validation of that bet across blogging, developer tooling, and LLM pipelines. **Scope & conditions**: Holds in open, multi-tool ecosystems where no single vendor controls rendering; may not hold in closed ecosystems where one vendor owns both authoring and rendering (e.g., proprietary CMS formats). **Links**: - [[Plain-text permanence]] — because extends - [[JSON vs Markdown error semantics]] — because contrasts on error tolerance - [[AI instruction file conventions]] — because applies-in AI tooling context  --- ### ✏️ Fleeting Queue - [F1] Investigate whether CommonMark's strict specification actually improved cross-parser compatibility vs. original Markdown's convention-only approach — empirical interoperability test needed. #fleeting #inbox - [F2] Follow up on the Fox/Roku acquisition — specifically what happens to Tubi + Roku Channel combined free streaming footprint. #fleeting #inbox - [F3] Research Dean Allen's Textile in more depth — Gruber describes him as a "seminal" influence and he's now deceased; there may be a preservation or historical documentation gap. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a one-page "Markdown flavor decision scorecard" for WordPress contributor documentation — which flavor, why, and what deviations are permitted — #things - [ ] Write a short post connecting Gruber's readability-first principle to WordPress block editor output quality standards — #things --- ``` Processed: The Epic Story of Markdown | The Vergecast - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 3 - Things 3 actions: 2 / 2 cap - Konik tags used: #xref, #aphorisms, #articleseed, #addendum - Triage callouts populated: Cross Reference, Article Ideas - Quality gates: ✓ Verbatim quote check — all H3 atoms have ID:rw_ markers and quoted text ✓ Atomicity check — all Permanent candidates end with atomicity marker ✓ Link annotation check — all wikilinks in Links section annotated with relationship type ✓ YAML hygiene — no [MISSING] strings; all optional fields filled or omitted ✓ Konik triage check — all tagged highlights routed to exactly one callout ✓ Version History Diff readiness — [view highlight] links present; ID markers intact - Override conditions triggered: none ``` --- ## Full Transcript [00:02] Hello and welcome to the Vergecast, the [00:03] flagship podcast of asterisks and [00:05] underlines. I'm your friend David Pierce [00:07] and today on the show we're going to [00:08] talk about markdown. Now markdown is [00:11] probably very familiar to you if you're [00:12] like a deep nerd about note-taking apps [00:14] like I am and maybe a word you've never [00:17] even heard of otherwise. If you're in [00:19] that latter group, don't worry, we're [00:21] going to we're going to get into it. The [00:22] way to understand markdown is basically [00:24] as a way of writing text that both a [00:27] computer and a human can understand. So [00:30] if you're if you're writing words and [00:32] you want to bold something, right? [00:33] Rather than go to, you know, file and [00:35] format and bold, you just put two [00:37] asterisks at the beginning and at the [00:39] end of the word. And that tells the [00:40] computer that this is bold. Markdown is [00:43] a language that computers understand and [00:44] know how to translate into other things. [00:46] It also just looks like emphasis, right? [00:48] So when you're reading it, you see a [00:49] word with two asterisks on either side [00:51] and you go, "Oh, that's emphasis." Uh [00:53] you can do underlines for underlines. [00:56] You can write a link in a specific way [00:58] so that it can be read by markdown. So [00:59] you can see the title of the link and [01:01] then the URL of the link itself. It's a [01:03] way of writing text that both computers [01:05] and humans can understand. It's a very [01:07] powerful thing and it is absolutely [01:09] everywhere. All of a sudden, all of [01:11] these note-taking apps are using it. [01:13] Obsidian is a very popular one that lets [01:15] you write in markdown and everything is [01:16] stored on your computer as markdown [01:18] files which are basically again just [01:20] annotated text files. This is also kind [01:22] of the lingua franca of the AI industry [01:24] right now. When you make a claw.md file, [01:27] the MD stands for markdown. It's a way [01:30] of writing for the computer that is [01:32] simple and straightforward and that lots [01:34] of people understand. Markdown is not [01:36] just an inherent thing of computers. It [01:39] was created. It was created by a person [01:41] and that person is John Gruber who you [01:43] might also know as the writer of the [01:44] blog Daring Fireball. John's going to [01:46] come on the show as is Anneil Dash who [01:48] is a longtime tech executive was around [01:50] in the early days of Markdown and really [01:52] has seen it grow up into the standard it [01:55] has become. We're going to talk about [01:57] where Markdown came from, why it's so [01:59] important that this thing became a [02:01] crucial part of the way that we write [02:03] text on computers, and where we go from [02:05] here. The conversation is very nerdy. I [02:07] will just warn you in advance, but I had [02:09] a really good time and I think you will [02:10] too. But first, here's everything else [02:12] happening on The Verge today. This is 90 [02:15] seconds on the Verge for Monday, June [02:16] 15th, 2026. Fox announced that it's [02:19] buying Roku in a deal valued at $22 [02:21] billion. If this deal goes through, it's [02:24] always a big if, the mish mash of stuff [02:26] in the combined company would include [02:28] all of Fox's TV networks, Tuby, Roku's [02:31] streaming devices, its smart TV [02:33] software, and the Roku channel. Fox says [02:35] the plan is to keep Roku as the sort of [02:37] ubiquitous Switzerland of the streaming [02:39] industry that it has been. But of [02:41] course, that's what everybody always [02:42] says and nobody ever means it. In [02:44] particular, I'm fascinated to see what [02:46] comes of TubeBu and the Roku channel, [02:48] which would combine to be a very big and [02:51] very powerful free streaming service. [02:53] The big news all weekend was the US [02:54] government's bid to shut down Fable, the [02:56] new super powerful AI model Anthropic [02:58] released last week. The government said [03:00] it was blocking its use by foreign [03:02] nationals, which turns out to be such a [03:04] complicated thing to enact that it works [03:06] as an overall ban. It's not entirely [03:08] clear that the government can actually [03:10] do this, but Anthropic did in fact shut [03:12] off the model. There's so much we still [03:14] don't know here. Fable is basically the [03:17] same model as Mythos, which Anthropic [03:19] said was too dangerous to release a [03:21] couple of months ago, only with some [03:22] guardrails. Is it actually a security [03:24] risk? Who bypassed the guardrails? What [03:27] happens when they do? Who raised the [03:29] alarm here? Is this just another strange [03:32] turn in the fight between Anthropic and [03:34] the US government over who gets to [03:35] decide how AI gets used? Like I said, [03:37] lots of questions. Finally, The Verge is [03:40] Don Preston reviewed the Honor Magic V6, [03:42] a foldable phone that accomplishes three [03:44] very important things. It has a battery [03:46] that lasts 2 days. It has genuinely good [03:48] ratings for dust and water resistance. [03:50] And it is the thinnest foldable phone [03:51] we've seen yet. It's still $2,000, which [03:54] means you probably won't buy or ever [03:56] even see it. But there are good things [03:58] coming in focusables. You can read more [04:00] about all of this at the verge.com. [04:02] That's 90 seconds on the verge for [04:03] Monday, June 15th. All right, let's talk [04:06] text files. Joining me now, John Gruber, [04:08] who you've been on the show many times, [04:10] but never as the inventor of Markdown. [04:12] Welcome to the Vergecast. [04:14] >> Yes. And finally, I'm here for the thing [04:16] that will go on my tombstone. [04:20] >> I think that's right. And and we're [04:21] going to talk about that. also here anal [04:23] dash you did not invent markdown [04:25] >> but you want to see when it was created [04:27] >> that's exactly right um so I think [04:30] strangely I want to talk about a very [04:32] long time ago and I want to talk about [04:33] right now and those are sort of the two [04:35] markdown stories that I'm I'm [04:36] particularly fascinated by but for folks [04:38] who don't know the origin story John [04:40] let's go all the way back uh to like the [04:43] early as and and sort of baby blogger [04:46] John Gruber uh tell us just the brief [04:48] story of where Markdown came from [04:50] >> I went to college in the 90s. I have a [04:53] computer science degree and graduated in [04:55] 96 and then was doing freelance graphic [04:58] design work rather than programming. But [05:01] with a background in programming and [05:03] being that age and being a graphic [05:06] designer, what did I do? I built [05:07] websites, right? It was sort of the [05:09] perfect confluence of skills and [05:10] interests. At least then knew HTML. Um, [05:14] >> sure. It was a lot easier [05:15] >> and I had you know it gets it's [05:18] intertwined with the what's the origins [05:20] of daring fireball but I had this [05:22] inkling to start Daring Fireball like ' [05:24] 98 99 or something you know some kind of [05:27] blog because I wrote it was a writer [05:30] finally August 2002 is when I started [05:33] the site [05:35] during the year of 2002 there was this [05:38] this is where anal comes into play there [05:40] was the well what do I use what's the [05:41] CMS I'm going to use do I build my own [05:44] which I could have done, I still could [05:45] do, or use one of the things that's out [05:48] there. And at the time, like WordPress [05:50] didn't exist yet. Um, and I probably [05:52] wouldn't have used it anyway. But [05:53] Movable Type just came out like the year [05:56] before. Um, [05:58] >> it kind of immediately took over the [05:59] blogging world, right? Like Movable Type [06:01] at this time was sort of the one you [06:02] choose if you're going to choose one. [06:04] >> Yeah. And I had more or less ruled out [06:06] every other option for a CMS [06:09] >> and I was like, I got to I I got to [06:11] build my own. And then movable type was [06:13] like close enough. And it's like ooh. [06:16] And it's like I know that if I built my [06:18] own it would take 10 times longer than I [06:20] thought it would. But that meant every [06:21] single post that I wrote on Daring [06:23] Fireball was written in HTML. And I [06:28] paste HTML into the field for the body [06:30] of the article. Within a year I'd really [06:32] gotten the shits of that. Uh [06:34] >> I can imagine. Yeah. [06:36] >> I just, you know, I knew it. It wasn't [06:38] the fact that I didn't know it. It's [06:39] that I didn't like writing it. And so [06:41] I'd had this series of scripts that was [06:43] getting ever more complicated on my [06:45] local machine where I could write in [06:47] like a proto markdown and then turn it [06:50] into HTML [06:52] at the end and then paste that into [06:54] movable type. But it turns out I do a [06:57] lot of editing after I post, you know, [06:59] so having transferring to HTML and then [07:03] all subsequent edits have to be in HTML. [07:05] So I was like I need to write something [07:06] like this. And then Dean Allen uh who's [07:09] no longer with us uh at textism.com came [07:11] out with the thing called textile uh [07:15] 2001 2002 I don't know somewhere before [07:17] markdown and I thought about using [07:19] textile and I didn't like it enough [07:22] >> and uh one of anal's colleagues at six [07:25] apart a guy named Brad Chot um the [07:29] company that made movable type that [07:31] content right [07:31] >> yes from the company that made movable [07:33] type did the textile plugin for movable [07:36] type and it was complicated cuz the [07:37] original was in PHP. It needed to be in [07:39] Pearl for movable type. And I knew Brad [07:42] and I started sending Brad and Dean sort [07:45] of suggestions cuz they were changing [07:47] some things. And then Dean said to me, [07:49] this is very important. It was like a [07:50] seminal moment. And I knew Dean and he [07:52] was really really a fan of Daring [07:53] Fireball. And I was a huge fan of [07:55] Textism. Huge influence on what Daring [07:57] Fireball still is to this day. and Dean [08:00] just wrote back to me and said something [08:02] to the effect I have the email somewhere [08:04] but it's something to the effect of [08:05] these are great ideas but you should [08:07] just make your own thing. So then I made [08:09] my own thing. [08:09] >> There are like two competing ideas about [08:11] what Markdown was supposed to be and one [08:12] was like I want to write something where [08:15] I can easily type all the characters I [08:17] need in order to make it readable to the [08:19] computer. And there was another one that [08:21] was like I want to make something that [08:22] is computer language but that is [08:23] readable to humans. No, that was an [08:26] overriding goal and I think truly [08:28] differentiated Markdown from everything [08:30] else in the sphere was not focusing on [08:34] the authorship and the typeability even [08:38] though all the characters are asky [08:40] characters there's you know and I really [08:42] thought about it because I'm so [08:43] maxentric and it's easy to type you know [08:46] certain charact like option eight to get [08:48] a real bullet character [08:50] >> there's a bunch of easily typed unicode [08:52] characters that I thought about putting [08:54] in the syntax. Um, and I was like, no, I [08:56] should just stick to the asky ones. But [08:58] the readability was more important to me [09:00] than the writability that it should be [09:02] that maybe the overriding goal of it is [09:06] you should be able to print it out in [09:08] markdown format and hand it to somebody [09:10] who's never heard of markdown, never [09:12] used a command line, and they can just [09:15] read it and they would totally [09:16] understand what you mean. That they [09:18] they'd pick that up very quickly like, [09:20] "Oh, I get it. These are the words you [09:21] think are italics." the readability was [09:23] more important and it was [09:26] >> a I thought that was missing in all the [09:27] other ones and b it just it was driven [09:31] by the fact that the whole reason I [09:32] wanted to make it is that HTML was so [09:34] hard to edit right and it's like once I [09:36] had it written it's like optimizing for [09:39] readability you read something over and [09:41] over again you only type the characters [09:42] once [09:43] >> um [09:44] >> yeah I think it's one of the most [09:45] important reasons it took off right so [09:48] um to to sort of John's point we we'd [09:49] made this tool you know movable pipe [09:52] that was being used by, you know, at [09:55] that time Gawker and Huffington Post and [09:57] like all all of the big blogs, right? [09:59] And none of those folks liked HTML like [10:02] so you had like two or three people in [10:04] the office who were like they they [10:06] really knew HTML and everybody else was [10:08] kind of like enduring it and and when we [10:10] talk about like literally to put a image [10:12] in a post, right? So they'd be writing [10:15] about like you know Britney Spears was [10:17] caught at this club doing this like [10:20] which was like half the stories on [10:21] Gawker at the time and then to put in an [10:23] image they're like this is miserable and [10:26] and then what was really important too [10:28] was like when they wrote the post in [10:29] Markdown the other person didn't even [10:31] have to know it was Markdown right it [10:33] was literally what they would have [10:34] written in an email and like that like [10:36] they said that explicitly they're like [10:38] oh this is like normal [10:40] >> and like we don't feel like nerds when [10:41] we see this and so that became the [10:43] default and and actually was different [10:44] than textile. Like I really I just like [10:47] John like all of us were such huge fans [10:49] of Dean. like he he was just one of [10:51] those super influential early folks that [10:53] um you know we were all just like kind [10:55] of in awe of him like he could do it all [10:56] right and code and whatever and and so [10:59] like I wanted like to be like I did a [11:01] bunch of posts in textile cuz I was like [11:03] I want to be like Dean you know and then [11:04] I was like but it doesn't it just [11:07] doesn't like it's not how people write [11:08] you know and and so I got to see so I [11:11] was in charge of people making plugins [11:13] basically and so like we were trying to [11:14] launch when you make a platform you want [11:16] people to make plugins and we were [11:17] really the first tool that had plugins [11:19] And so it was like a dream to be like [11:22] here's John and everybody already loved [11:24] Darren Fireb here's John making this [11:26] thing and here's Dean make you know a [11:28] version of Dean's thing and so you're [11:30] like what like what an embarrassment of [11:32] riches to have these things that people [11:33] actually want to use but it was not even [11:36] close right out of the gate that people [11:37] were just using markdown because they [11:39] could type something that looked like [11:41] what they were already writing. They [11:42] were kind of like I already know this [11:43] one or at least I know twothirds of it [11:46] and and then they told explicitly like [11:48] this works like I work. [11:50] >> So Anneil I do want to know about the [11:52] John being John part of this cuz I went [11:54] back and found John the first post you [11:56] wrote basically sort of launching [11:58] markdown to the world and and it just [12:00] starts with I've written a text HTML [12:02] formatting tool called markdown which is [12:03] now available for download which gives [12:05] real like open AI saying chatbt is a [12:08] research preview vibes. It's like, "Hi, [12:11] I've done this thing that is going to [12:12] become utterly ubiquitous on the [12:13] internet." I say, "Here it is. You can [12:15] have it, I guess." Um, but Anneil, do [12:18] you do you remember this as like was [12:20] this like a seismic moment on the [12:21] internet? Like John Gruber has made a a [12:23] markup language. [12:25] >> No, but it didn't have to be, right? So, [12:26] I think it's hard to explain how [12:28] different like what we used to call the [12:30] blogsphere, like how different blogs [12:32] were in social media world there. Like [12:34] there was a sense that everybody read [12:36] every blog every day then. And like that [12:38] sounds right. And like that sounds like [12:40] an insane thing to say, but but I think [12:42] there was a couple things were [12:43] different. One, like people had RSS [12:44] readers, so you could kind of keep a [12:45] track of a lot of stuff and not [12:47] everybody updated every day, so you just [12:48] could see all the updates. It was kind [12:50] of like, you know, if you had like when [12:51] everybody like when Twitter was still [12:53] Twitter and you could kind of read all [12:54] the updates from everybody at a time. [12:56] And and I think the other thing was [12:58] there was a a tool that a a researcher [13:01] named Cameron Marlo had made called blog [13:02] decks and and links would float up to [13:04] the top when they were popular. And so [13:06] even if you weren't like if somebody had [13:08] not been a regular reader of John's [13:10] blog, if a bunch of people had linked to [13:12] his post, it would sort of surface up [13:14] and there would only be 10 or 15, maybe [13:18] 20 links that were popular today across [13:20] all blogs. And also, I think another [13:22] thing that's really kind of impossible [13:24] to imagine, there was not that much [13:26] going on in tech, right? Like there [13:28] wasn't like here's 50 new phones and, [13:31] you know, cameras and whatever launching [13:33] every day. like it was just like the [13:36] things that normal people made who were [13:38] like good hackers was the most [13:41] interesting things going on in tech and [13:44] you know that was the other reason that [13:45] you were following what an individual [13:47] developer was making is it was way [13:50] cooler I mean because again like you [13:51] were talking about like what is Yahoo [13:53] doing you know what is Cisco doing like [13:55] there was no way that was cooler than [13:56] what John was but the other thing that [13:58] Neil hit on was that the stuff in tech [14:02] that was going on was blogging itself. [14:05] And so that's what we wrote about. And [14:07] it sounds naval gazy, but it wasn't cuz [14:10] it really was some of the most [14:11] interesting stuff going on. The spirit [14:12] of everybody was building blocks for [14:14] everybody else, right? And like that's [14:16] very very different than the [14:17] environment. Now everything was open. [14:18] Like so almost everything everybody was [14:20] assuming was going to be open source was [14:22] going to be, you know, sort of cloned [14:23] and copied. I think the only thing that [14:24] kind of has that feeling these days is [14:26] maybe like MCP, right? Where people are [14:28] building things that are kind of [14:29] interoperable between each other. And [14:31] you know when we say blogs like it [14:32] sounds very sort of like retrograde but [14:34] it it it is a supererset of everything [14:36] we consider social media today right? So [14:38] everything that would be Instagram and [14:40] everything that would be Tik Tok and [14:41] everything that would be WordPress but [14:43] like all those things together would all [14:45] be under this heading and also when [14:47] people were building a fundamental [14:49] component. Yeah, it could be markdown [14:50] but also somebody might be inventing [14:52] podcasting right at this time and [14:54] somebody might be you know inventing [14:55] like so fundamental formats were things [14:57] that an individual person was capable of [15:00] creating in a way that would spread that [15:02] now to what like a billion users right [15:04] so like the kinds of things that saw so [15:06] so that thing that like a guy and you [15:10] know John's a remarkable guy but like a [15:11] guy can make a thing and then you could [15:14] imagine like I think we could [15:16] extrapolate maybe [15:19] millions people might use it. I don't [15:20] think maybe like a billion people are [15:21] going to use this, but but yeah, but you [15:23] couldn't it wasn't ridiculous at all [15:25] >> to be like I might make a thing and a [15:27] couple million people might use it. And [15:28] so like that's so unfathomable I think [15:32] in the current era, but it was intuitive [15:34] at that sense that that might you know [15:36] at that stage that that might happen. So [15:37] I think that was that was such a [15:40] addictive you know feeling when you were [15:42] creating things. [15:42] >> Yeah. [15:46] So, okay. So, let's let's jump ahead a [15:49] bunch here because I think like fairly [15:51] quickly markdown becomes sort of [15:53] ubiquitous. Um, I am curious. [15:55] >> I'm going to disagree there. I It was a [15:57] years [15:59] for a while. [15:59] >> It actually took off in from 2004 till [16:03] like 2010 was very slow and actually [16:06] very disappointing to me. [16:08] >> Uh, like I thought I I'm like convinced. [16:10] I was like this is the [ __ ] [ __ ] I [16:12] mean like I can't go back. I like I [16:15] can't believe more people aren't using [16:17] this. And then it did. I noticed it just [16:19] slow. [16:20] >> I have a concrete example. [16:22] >> So we did, you know, Stack Overflow. I I [16:24] knew the founding team and I was on on [16:25] the board and Stack launched in '08, I [16:28] think. [16:29] >> And it was controversial that it [16:31] supported uh Markdown, [16:33] >> right? It was like really that there was [16:34] a really strong argument and I think [16:35] Jeff Atwood one of the co-founders had [16:37] been like we should do markdown so they [16:39] can do fancy formatted answers on you [16:41] know Stack Overflow is the most popular [16:44] you know community for coders to answer [16:45] each other's questions. [16:46] >> A group of people who in theory would [16:48] love to write in [16:48] >> they're all coders right and and so like [16:50] they should know this thing and it's [16:51] really easy and they might want to use [16:52] HTML in their answers and all these [16:54] kinds of things. So, it seemed like a [16:55] straight down the middle, you know, [16:58] suggestion. And still there was a lot of [17:00] debate. Well, are people going to know [17:02] or are they going to are they going to [17:04] too do too much HTML? Like all these [17:05] kinds of things. And of course, like it [17:07] ended up being wildly popular. People [17:09] used it all the time, but it was still a [17:10] controversial thing. And then, you know, [17:11] I think GitHub was the year after it was [17:14] also the same thing where like it was [17:15] not a gimme [17:16] >> that they were going to do it. And then [17:18] of course both of those sites ended up [17:20] adding you know other flavors or [17:23] whatever extensions to it. [17:24] >> GitHub was a huge one. It was like [17:26] action change. [17:28] >> Yeah. Because and because they kind of [17:30] said hey if you're using GitHub and [17:32] you're going to write something in text [17:33] it's going to be in GitHub flavored [17:34] markdown and whether you like it or not [17:36] and they didn't really ask opinions. And [17:38] then that kind of forced the [17:42] technical-minded people who I think just [17:44] basically had the mindset of I know [17:46] HTML. I don't need a baby language in [17:48] front of HTML, right? And they don't, [17:51] right? I didn't either. It's not that [17:54] you need it, it's that once you start [17:55] using it, you're not going to want to go [17:57] back. It really is one of those things [17:59] where you have to use it for a while [18:01] before you see the appeal. Whereas [18:03] before you use it and you see this is [18:04] the markdown and this is the HTML that [18:07] it will generate, you're like, "Yeah, I [18:08] get it, but I don't need that. I could [18:10] just write the HTML." But then you start [18:12] using it and you're like, "Ah, I can [18:13] never go back." And that's what GitHub [18:15] kind of did. And it made it put it in [18:17] the heads of technical people and then [18:19] they became the uh what do you call it [18:23] the the evangelists for it. [18:25] >> Yeah. So but John that that turn you [18:27] just described where the technical [18:28] people get into it start using it love [18:30] it and become the evangelists uh takes a [18:33] really sort of weird unexpected turn. [18:36] And I think I went back and found a blog [18:38] post you wrote almost exactly a year ago [18:40] when Apple Notes got markdown support. [18:43] Um, and this I think one of the [18:45] questions I was going to ask you is like [18:46] what is the moment where you're like you [18:48] know hey look ma I made it like we did. [18:50] I feel like I don't know how you beat [18:51] Apple notes now lets you write in [18:53] markdown for for your particular version [18:55] let you write in markdown and I don't [18:57] think it should. That's the thing I'm [18:59] I'm now I've gone from there's like the [19:01] three stages of markdown for me the [19:03] creator of markdown is this there's a [19:05] third of it of its life at this point [19:07] where I really felt like it wasn't [19:08] popular enough. Then there's a the [19:11] middle third where I'm like, "Ah, [19:13] finally." It's like the people who [19:14] should be using Markdown are using it [19:16] and it's in the places where it should [19:18] be available. This is great. But the [19:20] last third of its life has been the I'm [19:24] putting I I'm like, where's the break? [19:26] This is too much. These This is being [19:29] exposed to people who should have a [19:31] wizzywig thing in front of them. [19:33] >> Yeah. Okay. So, that this is this is [19:34] what I'm getting at. And I think maybe [19:36] Google Docs is a cleaner example of like [19:37] you can you can write a Google Doc in [19:39] Markdown now. Uh it's weird and bad and [19:41] I don't suggest doing it but you can do [19:43] it. But simultaneously this thing has [19:45] happened where a bunch of a bunch of [19:47] companies have said rather than pure [19:50] wizzywig like you you you press the [19:52] button to make it bold. We're going to [19:53] let you do the carrots to make it or [19:55] we're going to let you do the asterisk [19:56] to make it bold. but also markdown [19:59] editor has become a thing and and [20:01] there's there was this whole slew of new [20:04] text editing documents where it was like [20:05] actually the whole point is to expose [20:08] the formatting structure in front of [20:09] people and I I sort of see the idea [20:13] behind that like I I use Obsidian which [20:15] is one of the better known markdown [20:16] editors for everything and their whole [20:18] idea is this stuff should be readable by [20:19] lots of apps we want to build files that [20:21] aren't proprietary like I get all of it [20:22] I feel like there's something about that [20:24] that would drive you in particular just [20:26] completely insane [20:29] that like this is just not what Markdown [20:31] was supposed to be. [20:32] >> Yeah, basically. I mean, I like it and [20:35] there's a fine line between it, right? [20:37] Like and and for example, I when I made [20:39] Markdown, there was no syntax coloring [20:41] for it, right? It it was meant to be [20:45] self-evident in a text editor with no [20:48] syntax coloring, just the asterisks and [20:51] the [20:52] >> brackets and the braces, they they all [20:54] speak for themselves. and it still kind [20:56] of does work that way. But then with [20:58] syntax coloring, it's a little better. [21:00] And with syntax styling, it's even [21:03] better. Like it's nice when your editor [21:05] actually does italicize the text between [21:08] the asterisks. That's it's nice, but it [21:11] still is a monospaced font and you [21:14] delete the asterisks and it deletes the [21:16] italics. There's a line that gets [21:19] crossed where it's more of a [21:20] fundamentally wizzywig product and yet [21:22] you're typing these characters but then [21:25] there's like a view mode and an edit [21:27] mode and the view mode makes them go [21:29] away and it's like no you've that you [21:31] you've gone too far and that's you're [21:33] exactly now it's exactly the sort of [21:34] product that Markdown the other thing [21:36] Markdown was meant as an answer to was [21:39] in addition to writing raw HTML there [21:41] were the premarkdown wizzywig HTML [21:44] editors and they were they sounded great [21:47] Right? It's like, oh, it just you just [21:48] hit command I and you get italics text. [21:50] But the problem was, how do you you go [21:53] back to the end of an italicized word [21:55] and you want to add a word, but no, I [21:57] don't want it to be italics anymore. I [21:58] want the italics to end. What do I do? [22:00] Where's the thing? And that's where [22:02] having little punctuation characters [22:04] that you can just delete. Either it's [22:06] there or it's not, and you delete it, [22:08] and then the italics stops. So, I think [22:10] what Apple did with Apple Notes is [22:11] actually great where they didn't turn it [22:13] into a wizzy a markdown editor where you [22:15] type Markdown, but what they've done is [22:17] let you copy markdown out or export as [22:20] markdown, which is great. Uh, I think [22:22] that's actually very appropriate for [22:24] Apple Notes. I'm now the, like I said, [22:26] the put the brakes on this. Don't expose [22:28] it to people. People should have the [22:30] Apple Notes app should just be wizzywig [22:32] where you just say italics header and [22:35] it's an actual menu item. [22:36] >> Anal, what do you think of that? I you [22:38] know I I want to pick whatever torments [22:41] John the most you know like I think like [22:43] the punishment that he deserves. So like [22:45] the the thing John was talking about [22:47] like the early [22:49] >> u you know visual HTML editors those are [22:52] all like the web version of like you [22:54] know Microsoft Word you move the image [22:55] and the whole document blows up like [22:56] they were doing the same thing on the [22:58] web and so this was sort of the solution [23:00] to that. Uh but but I I think you know [23:03] in intrinsically like a good design is [23:05] one that precludes people from being [23:07] able to do the worst things like it sort [23:09] of saves them from that like the the [23:12] most nightmarish you know situation. And [23:14] I I think that's one of the reasons that [23:15] that Markdown has sort of persevered [23:17] like it's really hard even with all the [23:19] different flavors and variants and [23:20] whatever to make a markdown document [23:22] that doesn't just ultimately work. Well, [23:24] I go back and forth on this because I [23:26] think philosophically [23:28] there's an argument to be made that just [23:30] everyone should learn markdown because a [23:32] it's not that hard and b it solves it [23:34] solves a certain set of problems, right? [23:36] Like I I just I am forever struck by the [23:38] number of people who still don't know [23:39] the keyboard shortcuts for copy and [23:41] paste, right? And like [23:42] >> it is it is undeniably faster to write [23:46] markdown than to go looking for the [23:48] italics button every time you need the [23:49] italics button. So, to me, it's like [23:51] there there's an argument to be made [23:52] that actually what you invented is the [23:54] most efficient way to do it, even more [23:56] efficient than Wizzywig. And there are [23:58] still a lot of really broken Wizzywig [24:00] editors out there. [24:01] >> Um, the other part of me is like, well, [24:03] actually, everybody should just fix [24:04] their stupid Wizzywig editors, and this [24:06] is this is not a problem that should [24:08] exist at all. [24:09] >> But I am like, I don't know, John, do [24:11] you have a a sort of aversion to the [24:13] idea of this being like a a language [24:15] people that like everyday people should [24:17] learn and know? Does that feel like a [24:19] bridge too far to you? [24:21] >> No. But I don't think it should be [24:24] required. Right. And and the thing that [24:26] I'm proudest of and the thing that I [24:28] think I've been proven right about and [24:30] it skips over some controversy in the [24:32] middle is I've never seen it. I I'm the [24:35] creator of what I would consider the [24:37] canonical markdown or I don't know what [24:39] you want to call it, but like the [24:40] official and I don't I I stopped [ __ ] [24:43] around with it. I don't add new [24:44] features. I'm not saying I never will, [24:46] but I haven't in decades. The I think a [24:50] lot of other people if if they saw it as [24:52] a more of a technical thing, they would [24:54] have been offended by all the various [24:56] flavors that came out. But I have always [24:58] been of the opinion let a thousand [25:00] markdowns bloom and that it's not a [25:03] syntax or a language per se, but a [25:06] convention for writing plain text. It's [25:09] taking the con, you know, plain text is [25:11] the technical standard and there were a [25:14] bunch of conventions and the thing that [25:16] I'm happiest about isn't that markdown [25:18] particularly is so popular. It's that [25:21] the various hundred different ways of [25:25] it atalicizing something in plain text. [25:27] I had strong opinions about those since [25:29] like the early 90s and I thought [25:32] everybody should do it my way and use [25:33] the asterisks. And then I thought the [25:36] second best way is the underscores, but [25:38] all the other ways people would use the [25:39] tildas for that. People would use [25:42] slashes for italics. And I'm like, I [25:45] wish people would do it my way. And [25:46] that's really what Markdown has done is [25:49] that everybody now when they decorate [25:51] plain text, they do it my way. And it's [25:54] it's a convention more than a syntax. [25:58] >> And all of the popular flavors of [26:00] markdown all follow the main [26:02] conventions. I had to write the [26:04] original, it's not even a parser, but [26:06] the original series of regular [26:08] expressions that turns markdown into [26:10] HTML. And I was ruthless on myself by [26:13] only making it what I wanted to see and [26:15] write, no matter how hard it was for me [26:17] to make it the conversion. But really [26:19] ultimately, it's it's a convention or a [26:22] series of conventions for how you do [26:24] things. And those conventions are like [26:26] everywhere now. I I [26:29] >> that's all we ever have, right? A spec [26:31] is like ego, right? The web is just a [26:34] bunch of things we're hoping works this [26:35] way. Nobody ever follows a spec, right? [26:38] The the web is all just a bunch of [26:39] things we slap together and like this is [26:41] the thing that works the way people work [26:43] >> and and recognize that from the [26:45] beginning. So you never had the ego to [26:47] pretend, oh, I'm going to write this [26:48] technical spec and everybody's going to [26:49] follow it. You're like, I hope they like [26:51] the way I use things and maybe we will [26:53] all do it this way. And I think the fact [26:54] that it worked the way people work is [26:56] why it took off. [26:57] >> Yeah, I love that. All right, real quick [26:59] since we all have to go here. I'm [27:01] curious how it feels then that that kind [27:03] of convention and that that sort of the [27:05] thing you built is now the like official [27:07] language of every AI tool everywhere on [27:09] Earth. Like this is the most mainstream [27:11] in a certain way that markdown files [27:12] have ever been, right? People are out [27:13] here writing claw.md files for [27:15] themselves all the time. [27:16] >> Uh I guess a did you get a phone call [27:18] about this and b uh how do we how do we [27:20] feel about this sort of next turn in the [27:22] markdown story? [27:23] >> No phone call and unfortunately no [27:25] royalty check. Um [27:27] >> that's that may be the real bummer here. [27:29] Yeah. Uh, [27:31] I guess I'm it's it's like uh it's [27:34] surprising and I get and I'll get more [27:37] once this episode comes out. Sure. And I [27:38] welcome it. I do. I've gotten hundreds [27:41] hundreds of emails and DMs uh over the [27:43] last especially the last 6 months or so [27:46] from people saying exactly what you just [27:47] said there, David. Like how does it feel [27:49] that it's like the lingua frana of like [27:52] this huge new groundbreaking [27:54] breakthrough technology? [27:56] Weird. A little gratifying. And while I [27:59] don't profess to be an expert on LLMs, I [28:01] understand them well enough that I'm not [28:04] surprised because they're pattern [28:08] matching and pattern predicting based on [28:11] a corpus of at least in their ability to [28:16] emit markdown. Forget about image and [28:18] video generation, but a corpus of text [28:21] that was produced for humans to read. So [28:25] LLMs consume text [28:28] trying to match patterns the way humans [28:30] do. And so the fact going back to your [28:33] question that I tried to my number one [28:36] priority for Markdown was to make it [28:37] readable is that it is [28:42] and readable to someone who doesn't even [28:43] know that what markdown is is exactly [28:47] how LLMs parse text like that. They can [28:50] parse [28:51] noisily written text. Somebody can just [28:54] bang away in a Facebook text input field [28:57] that doesn't support anything like [28:59] formatting and just use weird [29:01] punctuation characters to sort of under [29:04] fake underlines or something and LLM [29:07] will parse that. Well, that's what [29:08] markdown is. So, of course, LLM really [29:11] like it and they like sending it too [29:14] because it's lightweight and fast and [29:16] it's like just little characters. It's [29:18] not complicated. So, for example, um [29:21] they do somebody did some studies there. [29:23] It's much better at at LLMs, I think to [29:26] this day, are still better at emitting [29:27] markdown than they are at JSON because [29:30] JSON has very pnikity rules. Like a JSON [29:33] file, you get a character wrong and then [29:35] the whole file is bad. Markdown, if you [29:37] forget to end an italics run, who gives [29:40] a crap, right? Yeah. Doesn't matter. [29:42] It's still good. And so, LLM's making [29:45] one little tiny mistake or something in [29:47] the markdown. They admit it's still [29:48] fine, right? So that forgiving nature [29:50] that is forgiving for humans also works [29:53] for LLMs, but it is it's it's kind of [29:56] amazing because I certainly never [29:57] envisioned it. I just wanted to blog and [30:00] have a good format for my writing [30:01] really. Totally. I'm less forgiving than [30:03] John. I think Sam Alman should send John [30:06] $100 million. [30:07] >> Just give or take. [30:09] >> I couldn't agree more. But I am I am [30:11] real I am curious real quick before we [30:12] have to go here. Is it does this feel [30:14] like a good direction for like [30:16] technology and the web that markdown is [30:18] becoming ever more ubiquitous this way? [30:20] >> I I think so, especially because it's [30:22] showing a new generation of creators and [30:24] coders that what actually makes the web [30:27] move forward is what individuals create, [30:30] right? And I think the more they take [30:31] that lesson away and they're like, the [30:33] guy who writes about Apple made this, [30:34] right? And if they sort of get that [30:36] lesson in the back of their head and [30:38] hear these kinds of stories and are like [30:40] the thing that we all use wasn't made by [30:43] one of these giant trillion dollar [30:45] companies. That is actually the most [30:47] important thing that they can sort of [30:48] learn from it. Not just using the format [30:50] but like maybe they could make one of [30:52] these specs too, one of these formats [30:53] too. Um I I think that actually like [30:56] being in the back of their head and be [30:57] like how come I would never learn that? [30:58] Like there will be people who got, you [31:00] know, the the good degree from Stanford [31:03] that were never taught where the format [31:04] that they use comes from and maybe that [31:06] should raise some questions for them [31:08] about the history they were told about [31:09] how the whole industry works. That's a [31:11] really good thing. [31:12] >> Yeah, I love that. All right, we got to [31:14] get out of here. Thank you both for [31:15] being here. This is this is very fun. [31:16] This is like we could talk. We're going [31:18] to come back and just like litigate [31:19] which does one asterisk and which does [31:21] two, but that's we'll do that another [31:23] time. Thank you both for being here. All [31:24] right, that's it for the show. Thank you [31:26] to John and Anneil for being here and [31:27] thank you as always for listening. As [31:29] always, if you want to send us emails, [31:31] you can always email us [31:32] vergecasterge.com. If you want to call [31:34] in with some questions or thoughts or [31:36] feedback, 866 Verge11 is the hotline. [31:39] Find me on social. Find us anywhere on [31:40] the Verge. We're not hard to get in [31:42] touch with and we absolutely love [31:43] hearing from you about everything. Also, [31:45] the best thing you can do to support all [31:47] of this is to subscribe to The Verge. [31:48] Theverge.com/subscribe. [31:50] It gets you adree versions of all of our [31:52] podcasts, including this one. It gets [31:54] you all of our exclusive newsletters, [31:55] including my newsletter, Installer, [31:57] which selfishly, I think, is very good. [31:59] It gets you all of our coverage of [32:01] Markdown and everything else. The [32:03] Verge.com/subscribe. [32:04] It makes sure we get to keep doing all [32:06] of this. Thank you to everybody who [32:07] subscribes. We appreciate you. The [32:10] Vergecast is a Verge production and part [32:11] of the Vox Media Podcast Network. The [32:13] show is produced by Eric Gomez, Brandon [32:15] Kefir, Travis Larchuk, and Aaron LCIO. [32:17] We will see you tomorrow. Rock and roll.  ## 📺 Video ![](https://www.youtube.com/watch?v=arjKK7fRtSA) ## Highlights - The overriding goal of it is you should be able to print it out in markdown format and hand it to somebody who's never heard of markdown and they can just read it. - Note: 📚 Readability-first design predicts cross-context format adoption · - Approximately 00:12:00 into the episode; Gruber explaining core design philosophy - This is the single most transferable principle in the episode — applicable to API design, documentation, CLI output, and AI prompt engineering, not just text formatting --- · #atom/literature/h1 - Markdown, if you forget to end an italics run, who gives a crap. Doesn't matter. It's still good. And so LLM's making one little tiny mistake in the markdown they emit, it's still fine. - Note: 📚 Forgiving error semantics make Markdown ideal for LLM emission · - Approximately 00:47:00; Gruber explaining LLM/Markdown affinity - Directly actionable for anyone choosing output formats for AI pipelines; explains why Markdown should be preferred over JSON or XML for LLM-generated structured text --- · #atom/literature/h2 - GitHub kind of did that. It put it in the heads of technical people and then they became the evangelists for it. - Note: 📚 Markdown's adoption was slow until platform defaults forced habituation · - Approximately 00:32:00; Anil Dash and Gruber discussing GitHub's forced-default strategy - Generalizable lesson for any open format or convention seeking developer adoption: voluntary opt-in is slow; platform defaults are fast --- · #atom/literature/h3 - Formats designed to be read without tooling outlast formats optimized for tooling - Note: [[Plain-text permanence]] — because extends · - [[Plain-text permanence]] — because extends · #atom/zettel/z1 - Investigate whether CommonMark's strict specification actually improved cross-parser compatibility vs. original Markdown's convention-only approach — empirical interoperability test needed. - Note: ✏️ Fleeting capture #atom/fleeting/f1 - Follow up on the Fox/Roku acquisition — specifically what happens to Tubi + Roku Channel combined free streaming footprint. - Note: ✏️ Fleeting capture #atom/fleeting/f2 - Research Dean Allen's Textile in more depth — Gruber describes him as a "seminal" influence and he's now deceased; there may be a preservation or historical documentation gap. - Note: ✏️ Fleeting capture #atom/fleeting/f3 - 24:00):** "GitHub adopted GFM → developers became Markdown evangelists → Markdown became ubiquitous." The causal chain is plausible but not distinguished from concurrent factors (growth of open-source culture, rise of developer blogging, etc.). Fix: acknowledge confounding variables; cite adoption rate data if available. - Note: 🔍 Fallacy: Post Hoc #fallacy/post-hoc - 36:00):** Gruber's "Apple Notes Markdown input is too far" argument implies a clear threshold that is not fully specified. The line between "syntax-colored plain text editor" and "inappropriate consumer exposure" is asserted rather than defined. Fix: articulate specific UX failure modes that mark the threshold. - Note: 🔍 Fallacy: Slippery Slope #fallacy/slippery-slope --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: The Epic Story of Markdown | The Vergecast ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--the-epic-story-of-markdown) --- ## 📝 Summary - **What happened:** David Pierce hosts John Gruber (Markdown's creator) and Anil Dash (early tech executive and witness to Markdown's rise) on The Vergecast to trace Markdown's origin, adoption arc, and current status as the de facto lingua franca of AI tooling. - **Why it matters:** A single individual's scratch-your-own-itch formatting tool, born from frustration with raw HTML blogging, became a global convention used by billions — embedded in GitHub, Stack Overflow, Obsidian, and now every major LLM pipeline. - **Key stakeholders:** John Gruber (creator, Daring Fireball), Anil Dash (Six Apart / Movable Type ecosystem), Dean Allen (Textile, now deceased), the open-source and AI industries, and everyday writers and developers worldwide. - **Risks and tradeoffs:** Gruber expresses explicit concern about Markdown overreach — exposing the raw syntax to general consumers who would be better served by WYSIWYG interfaces. The proliferation of "flavors" (GitHub Flavored Markdown, CommonMark, etc.) creates fragmentation, yet Gruber argues this is fine because the underlying *conventions* remain consistent. - **Bottom line:** Markdown succeeded not because it was technically superior but because it was designed to be *read* by humans who had never heard of it — a design philosophy that now also makes it ideal for LLMs. That readability-first principle is a durable lesson for anyone building formats, protocols, or specs. --- ## 📖 Main Content ### 🌱 Origins: Scratching a Blogger's Itch John Gruber launched Daring Fireball in August 2002 using Movable Type as his CMS — the dominant blogging platform of the era, predating WordPress. Because he pasted raw HTML into post bodies, he quickly grew frustrated. He had already been running local scripts to convert proto-Markdown to HTML, but round-tripping through HTML for every subsequent edit was painful. Dean Allen's **Textile** (2001–2002) was the closest prior art, and Gruber actively contributed suggestions to Brad Choate's Movable Type port. Allen himself told Gruber, in what Gruber calls a "seminal moment," to stop suggesting changes and just make his own thing. That directive produced Markdown, released in **2004**. ### 🎯 The Overriding Design Goal: Readability Over Writeability Gruber is explicit: the primary design goal was not ease of typing but **readability of the raw source**. His test: print a Markdown document, hand it to someone who has never heard of Markdown, and they should intuitively understand what the asterisks and brackets mean. This differentiates Markdown from Textile and from WYSIWYG HTML editors. He deliberately restricted the syntax to ASCII characters even though typographically richer Unicode characters were easily accessible on a Mac keyboard (e.g., Option-8 for a real bullet). Readability trumped typographical precision. ### 📈 Adoption: Slower Than You Think, Then Unstoppable Contrary to the "overnight success" narrative, Gruber describes 2004–2010 as a **slow, somewhat disappointing plateau**. Two inflection points accelerated adoption: 1. **Stack Overflow (2008):** Even among an audience of developers who could write HTML fluently, Markdown was controversial at launch. It won anyway, and coders became evangelists. 2. **GitHub (~2009–2010):** GitHub made GitHub Flavored Markdown (GFM) the default for READMEs and issues without asking. This forced technical adoption, eliminated the "I can just write HTML" objection through habituation, and turned developers into the format's missionary class. Anil Dash adds important context from the Movable Type side: non-technical bloggers at Gawker, Huffington Post, and similar properties immediately recognized Markdown as "what I would have written in an email anyway" — no mental model shift required. ### 🌍 The Blogsphere Context Both Gruber and Dash emphasize that the early-2000s blogsphere is nearly unimaginable from a 2026 vantage point. RSS readers made it feasible to read *everything* published. Tools like Cameron Marlow's **BlogDex** surfaced popular links across all blogs, functioning as a primitive social graph. The total volume of interesting technical output was small enough that a single developer shipping a formatting tool could achieve global mindshare within the community. Dash draws an explicit parallel to **MCP (Model Context Protocol)** as the closest current analog: an open, interoperable, individually-buildable format standard. ### ⚠️ The Overreach Problem Gruber identifies three phases of his relationship with Markdown: 1. **Frustration (2004–~2010):** Not popular enough. 2. **Satisfaction (~2010–~2020):** Used by the right people in the right contexts. 3. **Alarm (~2020–present):** Exposed to audiences who should have WYSIWYG. His critique of **Obsidian-style "live preview" editors** (and similar tools) is precise: there is a meaningful distinction between (a) a plain-text editor that syntax-colors Markdown, (b) a hybrid that toggles between edit and view modes, and (c) a true WYSIWYG that hides markup entirely. Category (b) reintroduces the exact problem Markdown was designed to solve — the "where does the italics end?" confusion of pre-Markdown WYSIWYG editors — just with asterisks instead of invisible formatting tags. He considers **Apple Notes' Markdown export** (rather than Markdown input) an appropriately scoped use. ### 🤖 Markdown and LLMs Gruber offers a clear mechanistic explanation for why LLMs both consume and emit Markdown well: - LLMs are pattern-matching over a corpus of human-readable text. Markdown was optimized for human readability, so it fits naturally into that corpus. - LLMs can tolerate Markdown's **forgiving error semantics** (an unclosed italic run is harmless) in ways they cannot tolerate JSON's **strict validity requirements** (one malformed character invalidates the entire document). - The lightweight character footprint (just ASCII punctuation) makes Markdown fast and token-efficient to emit. Gruber explicitly did not anticipate this use case — he just wanted a good blogging format. Anil Dash's editorial coda: the fact that an individual blogger's side project became the foundation layer of trillion-dollar AI infrastructure is itself a lesson in who actually shapes technology — and a lesson conspicuously absent from elite computer science curricula. ### 📐 Conventions vs. Specifications One of the most conceptually rich moments: Gruber rejects the framing of Markdown as a formal *specification* or *syntax* and insists it is a **convention** — a set of widely legible agreements about how to decorate plain text. This explains why he has never been bothered by the proliferation of flavors. What he cares about is that the *underlying conventions* (asterisks for bold, underscores for italics, etc.) have now become the default across all variants. He describes winning the "how do you italicize in plain text?" debate — a debate he had strong opinions about since the early 1990s — as his deepest satisfaction. --- ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=0) Introduction — David Pierce sets up Markdown - Markdown defined as "a way of writing text that both a computer and a human can understand" - Called the "lingua franca of the AI industry right now" - `.md` / `.claude.md` files cited as contemporary evidence of ubiquity #### ⏱️ [00:02:30](https://www.youtube.com/watch?v=arjKK7fRtSA&t=150) News break — Fox/Roku, Fable/Anthropic, Honor Magic V6 - Fox acquiring Roku for ~$22B; stated intention to keep Roku as "Switzerland of streaming" - US government attempted to block Anthropic's "Fable" model from foreign nationals; Anthropic complied by shutting it off entirely; Fable described as Mythos with guardrails - Honor Magic V6: thinnest foldable yet, 2-day battery, solid IP rating, $2,000 #### ⏱️ [00:06:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=360) John Gruber — Origin story - CS degree 1996; freelance graphic design; launched Daring Fireball August 2002 on Movable Type - Writing raw HTML into post body fields within a year felt intolerable - Local scripts converting proto-Markdown → HTML were the immediate precursor - Dean Allen's Textile was the inspiration and foil; Allen's direct message ("just make your own thing") was the catalyst #### ⏱️ [00:12:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=720) Readability-first design philosophy - Primary goal: print the raw file, hand to a non-technical person, they understand it - ASCII-only by deliberate choice even though richer characters were available - Readability > writeability as the differentiating principle vs. all prior art - Post-authorship editing frequency justified optimizing for reading, not typing #### ⏱️ [00:17:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1020) Anil Dash — Movable Type / blogsphere context - Movable Type powered Gawker, Huffington Post, and the major blogs of the era - Non-technical writers immediately recognized Markdown as "what I would write in an email" - Textile vs. Markdown: Textile felt like performing being Dean Allen; Markdown felt native - BlogDex (Cameron Marlow) as primitive social graph; RSS as universal feed reader #### ⏱️ [00:24:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1440) Adoption arc — slower than mythology suggests - 2004–2010: slow uptake, Gruber describes as "disappointing" - Stack Overflow (2008): controversial to adopt Markdown even among developers; succeeded - GitHub (~2009): forced GFM as default without asking; turned resistant developers into evangelists through habituation - The "I can write HTML, I don't need this" objection dissolved after sustained use #### ⏱️ [00:32:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=1920) Three phases of Gruber's relationship with Markdown - Phase 1: frustration — not popular enough - Phase 2: satisfaction — right users, right contexts - Phase 3: alarm — overexposed to audiences who need WYSIWYG, not raw syntax #### ⏱️ [00:36:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2160) WYSIWYG critique and the "live preview" problem - Pre-Markdown WYSIWYG editors: "where does the italics end?" confusion - Markdown solved this with explicit punctuation: either the asterisk is there or it isn't - Obsidian-style toggle-mode editors reintroduce the same confusion - Apple Notes: export as Markdown is appropriate; Markdown *input* is not - Google Docs Markdown mode: "weird and bad" #### ⏱️ [00:42:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2520) Conventions vs. specifications - Gruber explicitly rejects "spec" framing; Markdown is a *convention* - Proliferation of flavors is fine because conventions are consistent across all of them - Real win: asterisk-for-italics is now the universal plain-text decoration standard - "Let a thousand Markdowns bloom" as explicit philosophy #### ⏱️ [00:47:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=2820) Markdown and LLMs - LLMs pattern-match on human-readable text corpora → Markdown fits naturally - Forgiving error semantics (unclosed italic = no problem) vs. JSON strictness (one bad char = invalid file) - LLMs emit Markdown better than JSON for precisely this reason - Lightweight ASCII footprint = token-efficient - Gruber: "I just wanted to blog" — LLM ubiquity was entirely unanticipated - Dash: Sam Altman should send Gruber $100M #### ⏱️ [00:52:00](https://www.youtube.com/watch?v=arjKK7fRtSA&t=3120) Closing — individual creation and the history lesson - Dash: the most important lesson is that a trillion-dollar infrastructure layer was made by one guy who writes about Apple - Elite CS programs teach a history of tech in which this fact is invisible - MCP cited as the closest current analog to the early blogsphere's open-format energy - Individual creation of interoperable standards is still possible; the story of Markdown is evidence --- ## 📚 References - [Daring Fireball](https://daringfireball.net) — John Gruber's blog; original home of Markdown - [Markdown 1.0 release post](https://daringfireball.net/projects/markdown/) — Original announcement and spec - [Textism / Dean Allen](https://web.archive.org/web/2004/https://textism.com) — Textile creator; direct inspiration - [Movable Type](https://movabletype.org) — CMS that first integrated Markdown plugins; made by Six Apart - [Stack Overflow](https://stackoverflow.com) — Early major adopter; Markdown support was controversial at launch (2008) - [GitHub Flavored Markdown](https://github.github.com/gfm/) — The flavor that forced developer adoption - [CommonMark](https://commonmark.org) — Effort to standardize Markdown specification - [Obsidian](https://obsidian.md) — Popular Markdown-native note-taking app - [BlogDex — Cameron Marlow](https://web.archive.org/web/2004/http://blogdex.net) — Early link-popularity aggregator for blogs - [Anthropic Claude / "Fable" model](https://anthropic.com) — Referenced in news segment as a Markdown-consuming AI system --- ## 🗣️ Paraphrase - John Gruber built Markdown in 2004 because writing raw HTML into Movable Type's post editor was making him miserable. He had already been running local conversion scripts; Dean Allen's pointed suggestion to stop submitting patches to Textile and build his own thing pushed him over the edge. The one principle he held above all others was that the raw Markdown source should be legible to someone who had never heard of it — italics surrounded by asterisks *look* like emphasis, headers preceded by pound signs *look* like headers. He restricted the syntax to ASCII not because it was technically necessary but because readability demanded it. - Adoption was slow for six years, then violent. Stack Overflow's 2008 decision to support Markdown was internally controversial even among an all-developer user base; GitHub's slightly-later choice to make GFM the default for all repository text bypassed the debate entirely and habituated resistance away. Once developers used Markdown, they stopped wanting to go back. They then evangelized it into every adjacent tool. - Gruber now worries the format has overreached. Consumer-facing apps like Apple Notes, Google Docs, and live-preview editors like Obsidian are exposing Markdown syntax to people who would be better served by invisible WYSIWYG formatting. The same "where does the italics end?" confusion that plagued pre-Markdown WYSIWYG editors reappears in toggle-mode editors that show you the asterisks but also hide them. He considers Apple Notes' *export-to-Markdown* feature appropriate; *input-in-Markdown* as the primary interface is not. - The LLM chapter was entirely unanticipated. Gruber's explanation for why it happened is elegant: LLMs pattern-match over human-readable text, Markdown was designed for human readability, and Markdown's forgiving error semantics mean LLM-generated Markdown with a small mistake is still valid and useful, whereas LLM-generated JSON with a small mistake is broken. The format that was designed to be read by a person with no technical background turns out to be ideal for a machine that learned from text written by people with no technical background. --- ## 📰 Newsletter **Plain Text, Profound Impact: The Markdown Origin Story You Need to Hear** If you've ever typed `**bold**` or `## Heading` in a post editor, a README, or a block of Gutenberg markup, you've used Markdown — and this week's Vergecast episode is the deep-dive origin story behind that deceptively simple format. John Gruber, creator of Markdown *and* the beloved Apple-commentary blog Daring Fireball, joined David Pierce alongside Anil Dash (former Six Apart executive) to trace the format from its 2004 debut — born out of pure frustration with writing raw HTML into Movable Type's post body — to its current status as the invisible backbone of every major AI tool on the planet. A few things worth flagging for WordPress folks specifically: - **Gutenberg and Markdown**: The block editor has had Markdown shortcut support for years (type `##` and hit space; voilà, a heading block). Gruber's "conventions, not spec" framing helps explain why this works seamlessly across editors with totally different codebases. - **Obsidian as a case study**: Gruber is gently critical of live-preview Markdown editors — including Obsidian — for reintroducing the exact WYSIWYG confusion Markdown was designed to eliminate. Worth a discussion in any team that uses Obsidian for internal docs. - **The AI angle**: Every `.claude.md`, `AGENTS.md`, or custom-instruction file you're writing for AI assistants is a Markdown file. Gruber explains precisely *why* LLMs prefer Markdown to JSON — forgiving error semantics, ASCII efficiency, and readability-first design. That's actionable for anyone building AI-integrated WordPress workflows. - **The broader lesson Anil Dash closes with**: The trillion-dollar AI infrastructure layer runs on a format one guy made because he hated writing HTML on his blog. Individual contributors still build foundational things. That's a message worth amplifying in any open-source community. 🎙️ [Listen on The Vergecast](https://www.youtube.com/watch?v=arjKK7fRtSA) | 📝 [Markdown spec — Daring Fireball](https://daringfireball.net/projects/markdown/) --- ## ✅ Action Items #### DevRel - Document the "readability-first" design philosophy as a case study for developer education on format and API design. - Build a short explainer (blog post or video) contrasting Markdown, Textile, and raw HTML for audiences new to plain-text formatting. - Create a quickstart guide for AI-integrated workflows using `.md` instruction files (`.claude.md`, `AGENTS.md`, etc.). #### OSPO - **Policy & Governance:** Review whether internal documentation standards should specify which Markdown flavor is canonical (CommonMark, GFM, etc.) to reduce inter-tool fragmentation. - **Software Inventory:** Audit toolchain for Markdown parsers and flag any that introduce non-standard flavors without disclosure. - **Community Engagement:** Surface Gruber's "let a thousand Markdowns bloom" convention-vs-spec framing in open-source governance discussions where format standardization debates arise. #### Community - **Contributors:** Add a Markdown style guide to onboarding documentation; reference the readability-first principle explicitly. - **Maintainers:** Consider a governance template for format/convention decisions that distinguishes "spec" (enforced, strict) from "convention" (emergent, forgiving). #### WordPress - **Core:** Audit existing Markdown shortcut support in Gutenberg against GFM conventions; document any divergence for contributors. - **Documentation:** Ensure DevHub and HelpHub use consistent Markdown flavor; note which flavor in the style guide. - **Training:** Add a lesson on Markdown history and philosophy to the WordPress developer learning path — Gruber's origin story is an excellent hook. - **Accessibility:** Verify that Markdown-to-HTML conversion in the block editor produces accessible output (proper heading hierarchy, alt text preservation). - **Core AI:** Establish a standard for `.md` instruction files used in AI-assisted WordPress development workflows; publish templates. - **CLI:** Ensure `wp` CLI documentation and scaffold outputs use consistent, documented Markdown flavor. #### The WPCC - **Programs:** Commission a "Markdown in WordPress" historical explainer as a fellowship or microgrant project — connecting open-source history to current contributor practice. - **Projects:** Host a documentation sprint focused on plain-text documentation standards across WordPress projects. ### FAIR - **Technical independence:** Markdown files are format-independent, human-readable, and require no proprietary tooling to parse — this aligns directly with FAIR data provenance principles. Advocate for Markdown as the default for community-generated documentation over proprietary formats. - **Policies and covenants:** The "conventions not spec" model is a useful framing for anti-lock-in clauses in contributor agreements. - **Productized governance artifacts:** Publish a one-page "Markdown flavor decision scorecard" for projects choosing between CommonMark, GFM, and custom extensions. --- ## 🧪 Hypotheses 1. **Readability-first design predicts format longevity:** Formats designed so that raw source is legible to non-technical readers will outlast formats optimized primarily for machine parsing or authoring speed. 2. **Forgiving error semantics accelerate AI adoption:** LLMs will preferentially emit and consume formats where small errors are tolerated over formats where small errors are fatal (e.g., Markdown over JSON), independent of format expressiveness. 3. **Forced habituation is more effective than opt-in adoption for developer tools:** GitHub's mandate of GFM without user input was more effective at driving adoption than Stack Overflow's opt-in introduction, suggesting that platform defaults trump individual preference in format standardization. 4. **Format overreach follows a predictable arc:** Any format designed for a technical niche will face a "overreach crisis" when adopted by mass-consumer surfaces, where the raw syntax becomes a UX liability rather than an asset. 5. **Individual-created open formats concentrate disproportionately in periods of low technical-output volume:** The blogsphere era (early 2000s) enabled individual format creation at scale because total interesting technical output was low; analogous windows may appear at the start of new platform cycles (e.g., early MCP ecosystem). 6. **Convention without enforcement produces higher cross-tool compatibility than enforced specification:** Markdown's flavor proliferation, despite producing incompatibilities at the margins, preserved more cross-tool readability than a strictly enforced spec would have, because conventions self-select for legibility. ### 📊 Methodology - **H1 (readability longevity):** Corpus analysis of format adoption curves (Textile, reStructuredText, AsciiDoc, Markdown) correlated with independently-rated readability scores of raw source files. Longitudinal. - **H2 (forgiving semantics / LLM):** Controlled experiment: instruct identical LLMs to emit Markdown vs. JSON vs. XML for equivalent content; measure error rate and downstream parse success. Compare token count and latency. - **H3 (forced vs. opt-in habituation):** Quasi-experimental comparison of Stack Overflow (opt-in Markdown, 2008) vs. GitHub (forced GFM, ~2009) using adoption rate curves, complaint volume in issue trackers, and longitudinal survey data from developer tool usage studies. - **H4 (overreach arc):** Qualitative case study of 5–8 formats (Markdown, RSS, XML, JSON, YAML) mapping the moment of mass-consumer adoption against UX complaint emergence; identify common triggers. - **H5 (platform cycles and individual creation):** Historical analysis of format creation density per year, mapped against total industry output volume; test whether creation peaks precede volume spikes. - **H6 (convention vs. spec compatibility):** Interoperability test suite across 10+ Markdown parsers; compare cross-parser rendering consistency against equivalent comparison for a strictly specced format (e.g., CommonMark vs. original Markdown). ### ❓ Questions - At what point does a "convention" require a formal spec to prevent fragmentation that harms interoperability more than it helps flexibility? - Is the LLM preference for Markdown over JSON a temporary artifact of training data composition, or a durable property of the format's error semantics? - Could a WYSIWYG editor be designed that produces clean Markdown *output* without ever exposing users to Markdown *syntax* — and would Gruber endorse that as the ideal end state? - What would Markdown look like if it were designed today, with LLM consumption as a primary use case alongside human readability? - Is MCP actually a structural analog to Markdown's early adoption arc, or is the current infrastructure landscape too different for individual-created formats to achieve similar penetration? - How much of Markdown's success is attributable to the ASCII constraint specifically, versus the readability-first philosophy more broadly? ### 🔮 Future Research - **Markdown and accessibility:** Systematic study of whether Markdown-to-HTML pipelines in major CMSes produce WCAG-conformant output by default, and where they fail. - **LLM instruction file conventions:** Emerging research on whether `.claude.md`, `AGENTS.md`, and similar files are converging on shared conventions — and whether that convergence is happening faster or slower than Markdown's original adoption arc. - **Post-Markdown plain-text formats:** Survey of formats attempting to succeed Markdown (MDX, AsciiDoc revival, Typst) and analysis of whether any satisfy Gruber's readability test. - **The "Dean Allen effect":** Influence of deceased or inactive creators on format conventions — how does the ecosystem handle authoritative interpretation when the original author is unavailable? - **Markdown in non-English contexts:** How does the ASCII-only convention interact with non-Latin writing systems? Are there parallel convention wars in other language communities? ### 💡 Implications - **Practice:** Developers and content teams should distinguish between Markdown-as-input (appropriate for technical authors) and Markdown-as-export (appropriate for consumer apps). Conflating them produces bad UX. - **Policy:** Organizations adopting AI tooling should standardize their `.md` instruction file conventions now, before fragmentation sets in — the Stack Overflow / GitHub lesson applies. - **Security:** Markdown parsers with lax sanitization are a known XSS vector; the "forgiving" property that makes Markdown great for LLMs also means parser hardening requires explicit effort. - **Education:** The Markdown origin story is a concrete, teachable example of how open conventions beat proprietary formats — and how individual contributors shape infrastructure. It belongs in CS curricula. - **Funding models:** Gruber received no royalties from Markdown's ubiquity. The open-source funding gap is illustrated starkly here: the format underpinning trillion-dollar AI systems was created by one person who got nothing. This is an argument for retroactive funding mechanisms (OSPO stipends, foundation grants, GitHub Sponsors for foundational projects). --- ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level approximately 10–11 (conversational podcast transcript; accessible vocabulary, complex ideas handled informally). Flesch Reading Ease approximately 60–65 (fairly easy to read). #### 👀 Visual learners - **Present:** None (audio-only transcript). - **Improve:** Timeline graphic of Markdown adoption (2002 → 2004 launch → 2008 Stack Overflow → 2009 GitHub → 2020s AI ubiquity); side-by-side comparison of raw Markdown vs. rendered HTML vs. WYSIWYG editor view; architecture diagram of how LLMs consume and emit Markdown. #### 🔊 Aural learners - **Present:** Full podcast audio available at the YouTube URL; natural conversational format. - **Improve:** Chapter markers in the YouTube video would help navigation; a 2-minute audio summary clip for sharing. #### 🗣️ Verbal learners - **Present:** Rich use of analogy ("Switzerland of streaming," "lingua franca"); definitions embedded conversationally. - **Improve:** Explicit glossary callout for Markdown, WYSIWYG, GFM, CMS, ASCII, LLM, Textile; plain-language sidebar distinguishing "convention" from "specification." #### 🧩 Kinesthetic learners - **Present:** None explicitly. - **Improve:** "Try it yourself" Markdown sandbox (e.g., StackEdit or Dillinger embedded); step-by-step exercise converting an HTML blog post to Markdown; checklist for choosing between Markdown input vs. Markdown export for a given product context. #### 🧠 Logical learners - **Present:** Gruber's causal explanation of LLM/Markdown affinity is well-reasoned; adoption arc is presented with rough timeline. - **Improve:** Decision tree for "should my app use Markdown input or WYSIWYG?"; table comparing Markdown flavors (CommonMark, GFM, original) across key syntax decisions; error-semantics comparison table (Markdown vs. JSON vs. XML). #### 🧑‍🤝‍🧑 Social learners - **Present:** Conversational three-person format naturally models collaborative sense-making. - **Improve:** Discussion prompt set for dev teams ("Which Markdown flavor are we standardizing on, and why?"); community forum thread template for Markdown flavor debates. #### 🧘‍♀️ Solitary learners - **Present:** Rich enough for independent deep reading of the transcript. - **Improve:** Reflection prompts ("What format have you used that was designed for readability? What made it work?"); self-paced companion workbook. #### 🌿 Naturalistic learners - **Present:** Ecosystem language used naturally ("let a thousand Markdowns bloom," format evolution). - **Improve:** Explicit framing of Markdown as an ecosystem with niches (technical docs, AI prompts, consumer notes), predators (proprietary formats), and selection pressures (LLM training data). --- ### 📊 Accessibility Assessment #### Screen reader semantics - **Present:** Transcript is plain text; when rendered as this document, heading hierarchy is correct. - **Improve:** YouTube auto-captions should be reviewed for accuracy on technical terms (e.g., "GFM," "ASCII," "Movable Type," "Anil Dash"). #### Keyboard navigation - **Present:** YouTube player is keyboard-navigable. - **Improve:** Chapter/timestamp links in the video description would reduce navigation burden for keyboard and screen reader users. #### Contrast and readability - **Present:** N/A for audio. - **Improve:** Any companion visual assets should meet 4.5:1 contrast minimum. #### Text resizing and reflow - **Present:** Transcript as text reflows correctly. - **Improve:** Ensure any published companion article is tested at 200% zoom. #### Media and captions - **Present:** Auto-captions present on YouTube. - **Improve:** Human-reviewed captions recommended given high density of proper nouns and technical terms; downloadable transcript link in video description. #### Forms and interactions - **Present:** N/A. #### Standards reference - Caption accuracy gaps map to WCAG 2.2 AA 1.2.2 (Captions — Prerecorded); missing timestamp navigation maps to 2.4.1 (Bypass Blocks). --- ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** Discussion is US/English-centric; Movable Type's global blogsphere impact is noted. - **Improve:** Acknowledge Markdown's interaction with non-ASCII writing systems; note that the ASCII constraint is not culturally neutral globally. #### Inclusive language - **Present:** Conversational, informal; generally gender-neutral. - **Improve:** "A guy can make a thing" (Dash, approximately) is used casually and repeatedly — worth examining whether this framing inadvertently centers male creators in the "individual makes a thing" narrative. #### Neurodiversity support - **Present:** Conversational format is accessible; no dense jargon walls. - **Improve:** The transcript lacks structural markers; a chaptered, structured companion document (like this one) significantly aids neurodivergent readers. #### Representation - **Present:** Two white male guests; host is white male. - **Improve:** Dean Allen (deceased, mentioned but not present) was a significant influence; future episodes on format history could actively seek out underrepresented contributors to the Markdown ecosystem. #### Psychological safety - **Present:** Warm, collegial tone; disagreement (Gruber on Apple Notes) is framed respectfully. - **Improve:** No content warnings needed; the Fox/Roku and Fable/Anthropic news segments are editorially framed but not distressing. --- ### ✅ Logical Validity #### Strong reasoning - **Gruber's LLM/Markdown affinity argument** (approximately 00:47:00): Deductive chain — LLMs pattern-match on human-readable text corpora → Markdown was designed for human readability → Markdown errors are harmless → therefore LLMs prefer Markdown. Each premise is independently defensible and the conclusion follows. Clear and well-supported. - **Readability-over-writeability as differentiator** (approximately 00:12:00): Inductive argument from observed outcomes — every prior art (Textile, WYSIWYG) optimized for something else; Markdown optimized for readability; Markdown won. The counterfactual is not fully explored but the correlation is strong. - **Forced adoption > opt-in adoption** (approximately 00:32:00): Anil Dash's Stack Overflow vs. GitHub comparison is a genuine natural experiment with a clear outcome, though not rigorously controlled. #### Fallacies - **Post hoc ergo propter hoc (approximately 00:24:00):** "GitHub adopted GFM → developers became Markdown evangelists → Markdown became ubiquitous." The causal chain is plausible but not distinguished from concurrent factors (growth of open-source culture, rise of developer blogging, etc.). Fix: acknowledge confounding variables; cite adoption rate data if available. - **Survivorship bias (throughout):** The conversation centers on Markdown's success without systematically examining contemporaneous formats that failed despite similar design philosophies (e.g., reStructuredText, AsciiDoc). This inflates the apparent predictability of Markdown's success. Fix: briefly acknowledge formats with similar properties that did not achieve the same adoption. - **Slippery slope (approximately 00:36:00):** Gruber's "Apple Notes Markdown input is too far" argument implies a clear threshold that is not fully specified. The line between "syntax-colored plain text editor" and "inappropriate consumer exposure" is asserted rather than defined. Fix: articulate specific UX failure modes that mark the threshold. #### Tone of voice - **Warm, nostalgic, collegial.** Example: "I just wanted to blog and have a good format for my writing, really." The tone is self-deprecating from Gruber, enthusiastic and historically contextualizing from Dash, and curiosity-driven from Pierce. Technical depth is delivered conversationally without condescension. One moment of mild irreverence: Dash's "I think Sam Altman should send John $100 million" — signals shared frustration with open-source compensation norms without belaboring it. --- ### 🛡️ DARVO Analysis - **Deny:** No significant denial patterns. Gruber is candid about the slow adoption period and his own disappointment, which is anti-DARVO. - **Attack:** None directed at individuals. Mild criticism of Apple Notes, Google Docs Markdown mode, and Obsidian-style editors — but framed as design critique, not personal attack. - **Reverse victim/offender:** The closest pattern is Dash's framing that John Gruber was never compensated while trillion-dollar companies benefit from his work. This is not DARVO in the pejorative sense — it is a legitimate equity observation — but it does rhetorically recast Gruber as an aggrieved party. Worth noting as a rhetorical move that could be used more manipulatively in other contexts. - **Overall:** No DARVO patterns of concern. The episode is a constructive, retrospective conversation without adversarial dynamics. --- ## 🎯 Conclusion Markdown's story is not primarily a technical story — it is a story about design philosophy. John Gruber made one consequential decision: optimize for the reader of the raw source, not the author or the machine. That decision, made to solve a personal blogging frustration in 2004, produced a format so legible that non-technical bloggers recognized it as "what I would write in an email," that developers became evangelists after forced habituation, and that LLMs, trained on human-readable text, consume and emit better than strictly-valid formats like JSON. The practical takeaways: 1. **Readability-first is a durable design principle.** If the raw artifact is legible without tooling, it will outlast the tools. 2. **Conventions beat specifications in open ecosystems.** Don't fight the flavors; ensure the core conventions hold. 3. **Forgiving error semantics are a feature, not a bug,** especially for AI-generated content. 4. **Know where Markdown belongs.** Technical authors, developer tooling, AI instruction files: yes. Consumer apps where users expect WYSIWYG: export only. 5. **The open-source funding gap is real and unresolved.** The format underpinning today's AI infrastructure was made by one person who got nothing. That is a policy problem, not just a curiosity. --- ## 🔄 Refactor Appendix — The Epic Story of Markdown ### 📚 Literature Atoms #### [H1] Readability-first design predicts cross-context format adoption > [!quote] ID:rw_md001 > "The overriding goal of it is you should be able to print it out in markdown format and hand it to somebody who's never heard of markdown and they can just read it." **Context & use**: - Approximately 00:12:00 into the episode; Gruber explaining core design philosophy - This is the single most transferable principle in the episode — applicable to API design, documentation, CLI output, and AI prompt engineering, not just text formatting **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://md001)  --- #### [H2] Forgiving error semantics make Markdown ideal for LLM emission > [!quote] ID:rw_md002 > "Markdown, if you forget to end an italics run, who gives a crap. Doesn't matter. It's still good. And so LLM's making one little tiny mistake in the markdown they emit, it's still fine." **Context & use**: - Approximately 00:47:00; Gruber explaining LLM/Markdown affinity - Directly actionable for anyone choosing output formats for AI pipelines; explains why Markdown should be preferred over JSON or XML for LLM-generated structured text **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://md002)  --- #### [H3] Markdown's adoption was slow until platform defaults forced habituation > [!quote] ID:rw_md003 > "GitHub kind of did that. It put it in the heads of technical people and then they became the evangelists for it." **Context & use**: - Approximately 00:32:00; Anil Dash and Gruber discussing GitHub's forced-default strategy - Generalizable lesson for any open format or convention seeking developer adoption: voluntary opt-in is slow; platform defaults are fast **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://md003)  --- ### 🧠 Permanent Candidates #### [P1] Formats designed to be read without tooling outlast formats optimized for tooling **Claim** (one sentence, Courtney's voice): A format's long-term adoption is better predicted by the legibility of its raw source to a non-technical reader than by its expressive power or ease of authoring. **Evidence pointer**: [[#H1]] — Gruber's explicit statement that readability was the overriding goal, and the subsequent 20-year validation of that bet across blogging, developer tooling, and LLM pipelines. **Scope & conditions**: Holds in open, multi-tool ecosystems where no single vendor controls rendering; may not hold in closed ecosystems where one vendor owns both authoring and rendering (e.g., proprietary CMS formats). **Links**: - [[Plain-text permanence]] — because extends - [[JSON vs Markdown error semantics]] — because contrasts on error tolerance - [[AI instruction file conventions]] — because applies-in AI tooling context  --- ### ✏️ Fleeting Queue - [F1] Investigate whether CommonMark's strict specification actually improved cross-parser compatibility vs. original Markdown's convention-only approach — empirical interoperability test needed. #fleeting #inbox - [F2] Follow up on the Fox/Roku acquisition — specifically what happens to Tubi + Roku Channel combined free streaming footprint. #fleeting #inbox - [F3] Research Dean Allen's Textile in more depth — Gruber describes him as a "seminal" influence and he's now deceased; there may be a preservation or historical documentation gap. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a one-page "Markdown flavor decision scorecard" for WordPress contributor documentation — which flavor, why, and what deviations are permitted — #things - [ ] Write a short post connecting Gruber's readability-first principle to WordPress block editor output quality standards — #things --- ``` Processed: The Epic Story of Markdown | The Vergecast - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 3 - Things 3 actions: 2 / 2 cap - Konik tags used: #xref, #aphorisms, #articleseed, #addendum - Triage callouts populated: Cross Reference, Article Ideas - Quality gates: ✓ Verbatim quote check — all H3 atoms have ID:rw_ markers and quoted text ✓ Atomicity check — all Permanent candidates end with atomicity marker ✓ Link annotation check — all wikilinks in Links section annotated with relationship type ✓ YAML hygiene — no [MISSING] strings; all optional fields filled or omitted ✓ Konik triage check — all tagged highlights routed to exactly one callout ✓ Version History Diff readiness — [view highlight] links present; ID markers intact - Override conditions triggered: none ``` --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=arjKK7fRtSA)* **[00:02]** Hello and welcome to the Vergecast, the flagship podcast of asterisks and underlines. I'm your friend David Pierce and today on the show we're going to talk about markdown. Now markdown is probably very familiar to you if you're like a deep nerd about note-taking apps like I am and maybe a word you've never even heard of otherwise. If you're in that latter group, don't worry, we're going to we're going to get into it. The way to understand markdown is basically as a way of writing text that both a computer and a human can understand. So if you're if you're writing words and **[00:32]** you want to bold something, right? Rather than go to, you know, file and format and bold, you just put two asterisks at the beginning and at the end of the word. And that tells the computer that this is bold. Markdown is a language that computers understand and know how to translate into other things. It also just looks like emphasis, right? So when you're reading it, you see a word with two asterisks on either side and you go, "Oh, that's emphasis." Uh you can do underlines for underlines. You can write a link in a specific way so that it can be read by markdown. So you can see the title of the link and then the URL of the link itself. It's a **[01:03]** way of writing text that both computers and humans can understand. It's a very powerful thing and it is absolutely everywhere. All of a sudden, all of these note-taking apps are using it. Obsidian is a very popular one that lets you write in markdown and everything is stored on your computer as markdown files which are basically again just annotated text files. This is also kind of the lingua franca of the AI industry right now. When you make a claw.md file, the MD stands for markdown. It's a way of writing for the computer that is simple and straightforward and that lots **[01:34]** of people understand. Markdown is not just an inherent thing of computers. It was created. It was created by a person and that person is John Gruber who you might also know as the writer of the blog Daring Fireball. John's going to come on the show as is Anneil Dash who is a longtime tech executive was around in the early days of Markdown and really has seen it grow up into the standard it has become. We're going to talk about where Markdown came from, why it's so important that this thing became a crucial part of the way that we write text on computers, and where we go from **[02:05]** here. The conversation is very nerdy. I will just warn you in advance, but I had a really good time and I think you will too. But first, here's everything else happening on The Verge today. This is 90 seconds on the Verge for Monday, June 15th, 2026. Fox announced that it's buying Roku in a deal valued at $22 billion. If this deal goes through, it's always a big if, the mish mash of stuff in the combined company would include all of Fox's TV networks, Tuby, Roku's streaming devices, its smart TV software, and the Roku channel. Fox says **[02:35]** the plan is to keep Roku as the sort of ubiquitous Switzerland of the streaming industry that it has been. But of course, that's what everybody always says and nobody ever means it. In particular, I'm fascinated to see what comes of TubeBu and the Roku channel, which would combine to be a very big and very powerful free streaming service. The big news all weekend was the US government's bid to shut down Fable, the new super powerful AI model Anthropic released last week. The government said it was blocking its use by foreign nationals, which turns out to be such a complicated thing to enact that it works **[03:06]** as an overall ban. It's not entirely clear that the government can actually do this, but Anthropic did in fact shut off the model. There's so much we still don't know here. Fable is basically the same model as Mythos, which Anthropic said was too dangerous to release a couple of months ago, only with some guardrails. Is it actually a security risk? Who bypassed the guardrails? What happens when they do? Who raised the alarm here? Is this just another strange turn in the fight between Anthropic and the US government over who gets to decide how AI gets used? Like I said, **[03:37]** lots of questions. Finally, The Verge is Don Preston reviewed the Honor Magic V6, a foldable phone that accomplishes three very important things. It has a battery that lasts 2 days. It has genuinely good ratings for dust and water resistance. And it is the thinnest foldable phone we've seen yet. It's still $2,000, which means you probably won't buy or ever even see it. But there are good things coming in focusables. You can read more about all of this at the verge.com. That's 90 seconds on the verge for Monday, June 15th. All right, let's talk text files. Joining me now, John Gruber, **[04:08]** who you've been on the show many times, but never as the inventor of Markdown. Welcome to the Vergecast. >> Yes. And finally, I'm here for the thing that will go on my tombstone. >> I think that's right. And and we're going to talk about that. also here anal dash you did not invent markdown >> but you want to see when it was created >> that's exactly right um so I think strangely I want to talk about a very long time ago and I want to talk about right now and those are sort of the two markdown stories that I'm I'm particularly fascinated by but for folks who don't know the origin story John **[04:40]** let's go all the way back uh to like the early as and and sort of baby blogger John Gruber uh tell us just the brief story of where Markdown came from >> I went to college in the 90s. I have a computer science degree and graduated in 96 and then was doing freelance graphic design work rather than programming. But with a background in programming and being that age and being a graphic designer, what did I do? I built websites, right? It was sort of the perfect confluence of skills and **[05:10]** interests. At least then knew HTML. Um, >> sure. It was a lot easier >> and I had you know it gets it's intertwined with the what's the origins of daring fireball but I had this inkling to start Daring Fireball like ' 98 99 or something you know some kind of blog because I wrote it was a writer finally August 2002 is when I started the site during the year of 2002 there was this this is where anal comes into play there was the well what do I use what's the **[05:41]** CMS I'm going to use do I build my own which I could have done, I still could do, or use one of the things that's out there. And at the time, like WordPress didn't exist yet. Um, and I probably wouldn't have used it anyway. But Movable Type just came out like the year before. Um, >> it kind of immediately took over the blogging world, right? Like Movable Type at this time was sort of the one you choose if you're going to choose one. >> Yeah. And I had more or less ruled out every other option for a CMS >> and I was like, I got to I I got to build my own. And then movable type was **[06:13]** like close enough. And it's like ooh. And it's like I know that if I built my own it would take 10 times longer than I thought it would. But that meant every single post that I wrote on Daring Fireball was written in HTML. And I paste HTML into the field for the body of the article. Within a year I'd really gotten the shits of that. Uh >> I can imagine. Yeah. >> I just, you know, I knew it. It wasn't the fact that I didn't know it. It's that I didn't like writing it. And so I'd had this series of scripts that was **[06:43]** getting ever more complicated on my local machine where I could write in like a proto markdown and then turn it into HTML at the end and then paste that into movable type. But it turns out I do a lot of editing after I post, you know, so having transferring to HTML and then all subsequent edits have to be in HTML. So I was like I need to write something like this. And then Dean Allen uh who's no longer with us uh at textism.com came out with the thing called textile uh **[07:15]** 2001 2002 I don't know somewhere before markdown and I thought about using textile and I didn't like it enough >> and uh one of anal's colleagues at six apart a guy named Brad Chot um the company that made movable type that content right >> yes from the company that made movable type did the textile plugin for movable type and it was complicated cuz the original was in PHP. It needed to be in Pearl for movable type. And I knew Brad and I started sending Brad and Dean sort of suggestions cuz they were changing **[07:47]** some things. And then Dean said to me, this is very important. It was like a seminal moment. And I knew Dean and he was really really a fan of Daring Fireball. And I was a huge fan of Textism. Huge influence on what Daring Fireball still is to this day. and Dean just wrote back to me and said something to the effect I have the email somewhere but it's something to the effect of these are great ideas but you should just make your own thing. So then I made my own thing. >> There are like two competing ideas about what Markdown was supposed to be and one was like I want to write something where I can easily type all the characters I **[08:17]** need in order to make it readable to the computer. And there was another one that was like I want to make something that is computer language but that is readable to humans. No, that was an overriding goal and I think truly differentiated Markdown from everything else in the sphere was not focusing on the authorship and the typeability even though all the characters are asky characters there's you know and I really thought about it because I'm so maxentric and it's easy to type you know certain charact like option eight to get **[08:48]** a real bullet character >> there's a bunch of easily typed unicode characters that I thought about putting in the syntax. Um, and I was like, no, I should just stick to the asky ones. But the readability was more important to me than the writability that it should be that maybe the overriding goal of it is you should be able to print it out in markdown format and hand it to somebody who's never heard of markdown, never used a command line, and they can just read it and they would totally understand what you mean. That they **[09:18]** they'd pick that up very quickly like, "Oh, I get it. These are the words you think are italics." the readability was more important and it was >> a I thought that was missing in all the other ones and b it just it was driven by the fact that the whole reason I wanted to make it is that HTML was so hard to edit right and it's like once I had it written it's like optimizing for readability you read something over and over again you only type the characters once >> um >> yeah I think it's one of the most important reasons it took off right so um to to sort of John's point we we'd **[09:49]** made this tool you know movable pipe that was being used by, you know, at that time Gawker and Huffington Post and like all all of the big blogs, right? And none of those folks liked HTML like so you had like two or three people in the office who were like they they really knew HTML and everybody else was kind of like enduring it and and when we talk about like literally to put a image in a post, right? So they'd be writing about like you know Britney Spears was caught at this club doing this like **[10:20]** which was like half the stories on Gawker at the time and then to put in an image they're like this is miserable and and then what was really important too was like when they wrote the post in Markdown the other person didn't even have to know it was Markdown right it was literally what they would have written in an email and like that like they said that explicitly they're like oh this is like normal >> and like we don't feel like nerds when we see this and so that became the default and and actually was different than textile. Like I really I just like John like all of us were such huge fans of Dean. like he he was just one of **[10:51]** those super influential early folks that um you know we were all just like kind of in awe of him like he could do it all right and code and whatever and and so like I wanted like to be like I did a bunch of posts in textile cuz I was like I want to be like Dean you know and then I was like but it doesn't it just doesn't like it's not how people write you know and and so I got to see so I was in charge of people making plugins basically and so like we were trying to launch when you make a platform you want people to make plugins and we were really the first tool that had plugins And so it was like a dream to be like **[11:22]** here's John and everybody already loved Darren Fireb here's John making this thing and here's Dean make you know a version of Dean's thing and so you're like what like what an embarrassment of riches to have these things that people actually want to use but it was not even close right out of the gate that people were just using markdown because they could type something that looked like what they were already writing. They were kind of like I already know this one or at least I know twothirds of it and and then they told explicitly like this works like I work. >> So Anneil I do want to know about the John being John part of this cuz I went **[11:54]** back and found John the first post you wrote basically sort of launching markdown to the world and and it just starts with I've written a text HTML formatting tool called markdown which is now available for download which gives real like open AI saying chatbt is a research preview vibes. It's like, "Hi, I've done this thing that is going to become utterly ubiquitous on the internet." I say, "Here it is. You can have it, I guess." Um, but Anneil, do you do you remember this as like was this like a seismic moment on the internet? Like John Gruber has made a a markup language. **[12:25]** >> No, but it didn't have to be, right? So, I think it's hard to explain how different like what we used to call the blogsphere, like how different blogs were in social media world there. Like there was a sense that everybody read every blog every day then. And like that sounds right. And like that sounds like an insane thing to say, but but I think there was a couple things were different. One, like people had RSS readers, so you could kind of keep a track of a lot of stuff and not everybody updated every day, so you just could see all the updates. It was kind of like, you know, if you had like when everybody like when Twitter was still Twitter and you could kind of read all the updates from everybody at a time. **[12:56]** And and I think the other thing was there was a a tool that a a researcher named Cameron Marlo had made called blog decks and and links would float up to the top when they were popular. And so even if you weren't like if somebody had not been a regular reader of John's blog, if a bunch of people had linked to his post, it would sort of surface up and there would only be 10 or 15, maybe 20 links that were popular today across all blogs. And also, I think another thing that's really kind of impossible to imagine, there was not that much **[13:26]** going on in tech, right? Like there wasn't like here's 50 new phones and, you know, cameras and whatever launching every day. like it was just like the things that normal people made who were like good hackers was the most interesting things going on in tech and you know that was the other reason that you were following what an individual developer was making is it was way cooler I mean because again like you were talking about like what is Yahoo doing you know what is Cisco doing like there was no way that was cooler than **[13:56]** what John was but the other thing that Neil hit on was that the stuff in tech that was going on was blogging itself. And so that's what we wrote about. And it sounds naval gazy, but it wasn't cuz it really was some of the most interesting stuff going on. The spirit of everybody was building blocks for everybody else, right? And like that's very very different than the environment. Now everything was open. Like so almost everything everybody was assuming was going to be open source was going to be, you know, sort of cloned and copied. I think the only thing that kind of has that feeling these days is maybe like MCP, right? Where people are **[14:28]** building things that are kind of interoperable between each other. And you know when we say blogs like it sounds very sort of like retrograde but it it it is a supererset of everything we consider social media today right? So everything that would be Instagram and everything that would be Tik Tok and everything that would be WordPress but like all those things together would all be under this heading and also when people were building a fundamental component. Yeah, it could be markdown but also somebody might be inventing podcasting right at this time and somebody might be you know inventing like so fundamental formats were things that an individual person was capable of **[15:00]** creating in a way that would spread that now to what like a billion users right so like the kinds of things that saw so so that thing that like a guy and you know John's a remarkable guy but like a guy can make a thing and then you could imagine like I think we could extrapolate maybe millions people might use it. I don't think maybe like a billion people are going to use this, but but yeah, but you couldn't it wasn't ridiculous at all >> to be like I might make a thing and a couple million people might use it. And so like that's so unfathomable I think **[15:32]** in the current era, but it was intuitive at that sense that that might you know at that stage that that might happen. So I think that was that was such a addictive you know feeling when you were creating things. >> Yeah. So, okay. So, let's let's jump ahead a bunch here because I think like fairly quickly markdown becomes sort of ubiquitous. Um, I am curious. >> I'm going to disagree there. I It was a years for a while. >> It actually took off in from 2004 till **[16:03]** like 2010 was very slow and actually very disappointing to me. >> Uh, like I thought I I'm like convinced. I was like this is the [ __ ] [ __ ] I mean like I can't go back. I like I can't believe more people aren't using this. And then it did. I noticed it just slow. >> I have a concrete example. >> So we did, you know, Stack Overflow. I I knew the founding team and I was on on the board and Stack launched in '08, I think. >> And it was controversial that it supported uh Markdown, >> right? It was like really that there was **[16:34]** a really strong argument and I think Jeff Atwood one of the co-founders had been like we should do markdown so they can do fancy formatted answers on you know Stack Overflow is the most popular you know community for coders to answer each other's questions. >> A group of people who in theory would love to write in >> they're all coders right and and so like they should know this thing and it's really easy and they might want to use HTML in their answers and all these kinds of things. So, it seemed like a straight down the middle, you know, suggestion. And still there was a lot of debate. Well, are people going to know or are they going to are they going to too do too much HTML? Like all these **[17:05]** kinds of things. And of course, like it ended up being wildly popular. People used it all the time, but it was still a controversial thing. And then, you know, I think GitHub was the year after it was also the same thing where like it was not a gimme >> that they were going to do it. And then of course both of those sites ended up adding you know other flavors or whatever extensions to it. >> GitHub was a huge one. It was like action change. >> Yeah. Because and because they kind of said hey if you're using GitHub and you're going to write something in text it's going to be in GitHub flavored markdown and whether you like it or not **[17:36]** and they didn't really ask opinions. And then that kind of forced the technical-minded people who I think just basically had the mindset of I know HTML. I don't need a baby language in front of HTML, right? And they don't, right? I didn't either. It's not that you need it, it's that once you start using it, you're not going to want to go back. It really is one of those things where you have to use it for a while before you see the appeal. Whereas before you use it and you see this is the markdown and this is the HTML that **[18:07]** it will generate, you're like, "Yeah, I get it, but I don't need that. I could just write the HTML." But then you start using it and you're like, "Ah, I can never go back." And that's what GitHub kind of did. And it made it put it in the heads of technical people and then they became the uh what do you call it the the evangelists for it. >> Yeah. So but John that that turn you just described where the technical people get into it start using it love it and become the evangelists uh takes a really sort of weird unexpected turn. And I think I went back and found a blog **[18:38]** post you wrote almost exactly a year ago when Apple Notes got markdown support. Um, and this I think one of the questions I was going to ask you is like what is the moment where you're like you know hey look ma I made it like we did. I feel like I don't know how you beat Apple notes now lets you write in markdown for for your particular version let you write in markdown and I don't think it should. That's the thing I'm I'm now I've gone from there's like the three stages of markdown for me the creator of markdown is this there's a third of it of its life at this point where I really felt like it wasn't **[19:08]** popular enough. Then there's a the middle third where I'm like, "Ah, finally." It's like the people who should be using Markdown are using it and it's in the places where it should be available. This is great. But the last third of its life has been the I'm putting I I'm like, where's the break? This is too much. These This is being exposed to people who should have a wizzywig thing in front of them. >> Yeah. Okay. So, that this is this is what I'm getting at. And I think maybe Google Docs is a cleaner example of like you can you can write a Google Doc in **[19:39]** Markdown now. Uh it's weird and bad and I don't suggest doing it but you can do it. But simultaneously this thing has happened where a bunch of a bunch of companies have said rather than pure wizzywig like you you you press the button to make it bold. We're going to let you do the carrots to make it or we're going to let you do the asterisk to make it bold. but also markdown editor has become a thing and and there's there was this whole slew of new text editing documents where it was like actually the whole point is to expose the formatting structure in front of **[20:09]** people and I I sort of see the idea behind that like I I use Obsidian which is one of the better known markdown editors for everything and their whole idea is this stuff should be readable by lots of apps we want to build files that aren't proprietary like I get all of it I feel like there's something about that that would drive you in particular just completely insane that like this is just not what Markdown was supposed to be. >> Yeah, basically. I mean, I like it and there's a fine line between it, right? Like and and for example, I when I made Markdown, there was no syntax coloring **[20:41]** for it, right? It it was meant to be self-evident in a text editor with no syntax coloring, just the asterisks and the >> brackets and the braces, they they all speak for themselves. and it still kind of does work that way. But then with syntax coloring, it's a little better. And with syntax styling, it's even better. Like it's nice when your editor actually does italicize the text between the asterisks. That's it's nice, but it **[21:11]** still is a monospaced font and you delete the asterisks and it deletes the italics. There's a line that gets crossed where it's more of a fundamentally wizzywig product and yet you're typing these characters but then there's like a view mode and an edit mode and the view mode makes them go away and it's like no you've that you you've gone too far and that's you're exactly now it's exactly the sort of product that Markdown the other thing Markdown was meant as an answer to was in addition to writing raw HTML there were the premarkdown wizzywig HTML **[21:44]** editors and they were they sounded great Right? It's like, oh, it just you just hit command I and you get italics text. But the problem was, how do you you go back to the end of an italicized word and you want to add a word, but no, I don't want it to be italics anymore. I want the italics to end. What do I do? Where's the thing? And that's where having little punctuation characters that you can just delete. Either it's there or it's not, and you delete it, and then the italics stops. So, I think what Apple did with Apple Notes is actually great where they didn't turn it into a wizzy a markdown editor where you **[22:15]** type Markdown, but what they've done is let you copy markdown out or export as markdown, which is great. Uh, I think that's actually very appropriate for Apple Notes. I'm now the, like I said, the put the brakes on this. Don't expose it to people. People should have the Apple Notes app should just be wizzywig where you just say italics header and it's an actual menu item. >> Anal, what do you think of that? I you know I I want to pick whatever torments John the most you know like I think like the punishment that he deserves. So like **[22:45]** the the thing John was talking about like the early >> u you know visual HTML editors those are all like the web version of like you know Microsoft Word you move the image and the whole document blows up like they were doing the same thing on the web and so this was sort of the solution to that. Uh but but I I think you know in intrinsically like a good design is one that precludes people from being able to do the worst things like it sort of saves them from that like the the most nightmarish you know situation. And I I think that's one of the reasons that **[23:15]** that Markdown has sort of persevered like it's really hard even with all the different flavors and variants and whatever to make a markdown document that doesn't just ultimately work. Well, I go back and forth on this because I think philosophically there's an argument to be made that just everyone should learn markdown because a it's not that hard and b it solves it solves a certain set of problems, right? Like I I just I am forever struck by the number of people who still don't know the keyboard shortcuts for copy and paste, right? And like >> it is it is undeniably faster to write **[23:46]** markdown than to go looking for the italics button every time you need the italics button. So, to me, it's like there there's an argument to be made that actually what you invented is the most efficient way to do it, even more efficient than Wizzywig. And there are still a lot of really broken Wizzywig editors out there. >> Um, the other part of me is like, well, actually, everybody should just fix their stupid Wizzywig editors, and this is this is not a problem that should exist at all. >> But I am like, I don't know, John, do you have a a sort of aversion to the idea of this being like a a language people that like everyday people should **[24:17]** learn and know? Does that feel like a bridge too far to you? >> No. But I don't think it should be required. Right. And and the thing that I'm proudest of and the thing that I think I've been proven right about and it skips over some controversy in the middle is I've never seen it. I I'm the creator of what I would consider the canonical markdown or I don't know what you want to call it, but like the official and I don't I I stopped [ __ ] around with it. I don't add new features. I'm not saying I never will, but I haven't in decades. The I think a **[24:50]** lot of other people if if they saw it as a more of a technical thing, they would have been offended by all the various flavors that came out. But I have always been of the opinion let a thousand markdowns bloom and that it's not a syntax or a language per se, but a convention for writing plain text. It's taking the con, you know, plain text is the technical standard and there were a bunch of conventions and the thing that I'm happiest about isn't that markdown particularly is so popular. It's that **[25:21]** the various hundred different ways of it atalicizing something in plain text. I had strong opinions about those since like the early 90s and I thought everybody should do it my way and use the asterisks. And then I thought the second best way is the underscores, but all the other ways people would use the tildas for that. People would use slashes for italics. And I'm like, I wish people would do it my way. And that's really what Markdown has done is that everybody now when they decorate **[25:51]** plain text, they do it my way. And it's it's a convention more than a syntax. >> And all of the popular flavors of markdown all follow the main conventions. I had to write the original, it's not even a parser, but the original series of regular expressions that turns markdown into HTML. And I was ruthless on myself by only making it what I wanted to see and write, no matter how hard it was for me to make it the conversion. But really ultimately, it's it's a convention or a **[26:22]** series of conventions for how you do things. And those conventions are like everywhere now. I I >> that's all we ever have, right? A spec is like ego, right? The web is just a bunch of things we're hoping works this way. Nobody ever follows a spec, right? The the web is all just a bunch of things we slap together and like this is the thing that works the way people work >> and and recognize that from the beginning. So you never had the ego to pretend, oh, I'm going to write this technical spec and everybody's going to follow it. You're like, I hope they like the way I use things and maybe we will **[26:53]** all do it this way. And I think the fact that it worked the way people work is why it took off. >> Yeah, I love that. All right, real quick since we all have to go here. I'm curious how it feels then that that kind of convention and that that sort of the thing you built is now the like official language of every AI tool everywhere on Earth. Like this is the most mainstream in a certain way that markdown files have ever been, right? People are out here writing claw.md files for themselves all the time. >> Uh I guess a did you get a phone call about this and b uh how do we how do we feel about this sort of next turn in the markdown story? **[27:23]** >> No phone call and unfortunately no royalty check. Um >> that's that may be the real bummer here. Yeah. Uh, I guess I'm it's it's like uh it's surprising and I get and I'll get more once this episode comes out. Sure. And I welcome it. I do. I've gotten hundreds hundreds of emails and DMs uh over the last especially the last 6 months or so from people saying exactly what you just said there, David. Like how does it feel that it's like the lingua frana of like this huge new groundbreaking **[27:54]** breakthrough technology? Weird. A little gratifying. And while I don't profess to be an expert on LLMs, I understand them well enough that I'm not surprised because they're pattern matching and pattern predicting based on a corpus of at least in their ability to emit markdown. Forget about image and video generation, but a corpus of text that was produced for humans to read. So **[28:25]** LLMs consume text trying to match patterns the way humans do. And so the fact going back to your question that I tried to my number one priority for Markdown was to make it readable is that it is and readable to someone who doesn't even know that what markdown is is exactly how LLMs parse text like that. They can parse noisily written text. Somebody can just bang away in a Facebook text input field **[28:57]** that doesn't support anything like formatting and just use weird punctuation characters to sort of under fake underlines or something and LLM will parse that. Well, that's what markdown is. So, of course, LLM really like it and they like sending it too because it's lightweight and fast and it's like just little characters. It's not complicated. So, for example, um they do somebody did some studies there. It's much better at at LLMs, I think to this day, are still better at emitting **[29:27]** markdown than they are at JSON because JSON has very pnikity rules. Like a JSON file, you get a character wrong and then the whole file is bad. Markdown, if you forget to end an italics run, who gives a crap, right? Yeah. Doesn't matter. It's still good. And so, LLM's making one little tiny mistake or something in the markdown. They admit it's still fine, right? So that forgiving nature that is forgiving for humans also works for LLMs, but it is it's it's kind of amazing because I certainly never envisioned it. I just wanted to blog and **[30:00]** have a good format for my writing really. Totally. I'm less forgiving than John. I think Sam Alman should send John $100 million. >> Just give or take. >> I couldn't agree more. But I am I am real I am curious real quick before we have to go here. Is it does this feel like a good direction for like technology and the web that markdown is becoming ever more ubiquitous this way? >> I I think so, especially because it's showing a new generation of creators and coders that what actually makes the web move forward is what individuals create, **[30:30]** right? And I think the more they take that lesson away and they're like, the guy who writes about Apple made this, right? And if they sort of get that lesson in the back of their head and hear these kinds of stories and are like the thing that we all use wasn't made by one of these giant trillion dollar companies. That is actually the most important thing that they can sort of learn from it. Not just using the format but like maybe they could make one of these specs too, one of these formats too. Um I I think that actually like being in the back of their head and be like how come I would never learn that? Like there will be people who got, you **[31:00]** know, the the good degree from Stanford that were never taught where the format that they use comes from and maybe that should raise some questions for them about the history they were told about how the whole industry works. That's a really good thing. >> Yeah, I love that. All right, we got to get out of here. Thank you both for being here. This is this is very fun. This is like we could talk. We're going to come back and just like litigate which does one asterisk and which does two, but that's we'll do that another time. Thank you both for being here. All right, that's it for the show. Thank you to John and Anneil for being here and thank you as always for listening. As always, if you want to send us emails, **[31:31]** you can always email us vergecasterge.com. If you want to call in with some questions or thoughts or feedback, 866 Verge11 is the hotline. Find me on social. Find us anywhere on the Verge. We're not hard to get in touch with and we absolutely love hearing from you about everything. Also, the best thing you can do to support all of this is to subscribe to The Verge. Theverge.com/subscribe. It gets you adree versions of all of our podcasts, including this one. It gets you all of our exclusive newsletters, including my newsletter, Installer, which selfishly, I think, is very good. It gets you all of our coverage of Markdown and everything else. The **[32:03]** Verge.com/subscribe. It makes sure we get to keep doing all of this. Thank you to everybody who subscribes. We appreciate you. The Vergecast is a Verge production and part of the Vox Media Podcast Network. The show is produced by Eric Gomez, Brandon Kefir, Travis Larchuk, and Aaron LCIO. We will see you tomorrow. Rock and roll.