Análisis Profundos

El nacimiento de Markdown: por qué el texto plano ganó la web

koboshiCo-founder
·11 min de lectura
El nacimiento de Markdown: por qué el texto plano ganó la web
Resumen

Markdown comenzó como un atajo de escritura para editores web. Dos décadas después alimenta READMEs de GitHub, sitios estáticos, aplicaciones de notas y la mayor parte de la salida de LLM. Esta publicación rastrea sus orígenes, lo compara con HTML y formatos de documentos enriquecidos, evalúa sus compensaciones reales y examina las herramientas y bibliotecas que lo mantienen vigente entre plataformas y lenguajes de programación.

Abre cualquier repositorio de GitHub. Lo primero que ves no es el código, sino un README.md. Ese archivo suele estar escrito en Markdown y es el documento más leído del proyecto. Las ofertas de empleo, los artículos académicos y los contratos legales rara vez viven en Markdown, pero una cantidad enorme de la escritura técnica de la web sí. Entender por qué implica volver a un formato diseñado para leerse antes de renderizarse.

De dónde vino Markdown

En 2004, John Gruber, un escritor de tecnología, publicó la especificación de sintaxis de Markdown con aportes de Aaron Swartz. El objetivo de Gruber era práctico: quería una forma de escribir para la web que se viera bien en texto plano y que luego pudiera convertirse a HTML. La web de entonces funcionaba con etiquetas. Escribir una entrada de blog significaba envolver cada párrafo, lista y enlace entre corchetes angulares. Gruber consideraba ese ruido innecesario para el tipo de prosa que la mayoría publicaba.

El resultado fue un pequeño conjunto de convenciones:

  • Los encabezados usan símbolos #.
  • Las listas usan - o *.
  • Los enlaces usan [texto](url).
  • El énfasis usa *texto* o _texto_.
  • El código usa acentos graves.

Estas convenciones provenían de hábitos de correo electrónico, Usenet y texto plano que los escritores ya conocían. Markdown no inventó mucho. Solo puso las reglas por escrito.

Gruber también publicó una implementación de referencia, Markdown.pl, un script en Perl que convertía la sintaxis a HTML. La combinación de un formato fuente legible y un formato de salida determinista facilitó su adopción. Los escritores obtuvieron un archivo que podían editar en cualquier editor de texto. Los editores obtuvieron HTML limpio que podían estilizar con CSS.

Markdown no es HTML

Esto suena obvio, pero la distinción importa técnicamente. HTML es un formato de documento estructurado. Describe elementos, atributos, anidamiento y comportamiento. A un navegador no le importa cómo se ve la fuente para un humano; le importa el DOM que puede construir a partir del marcado.

Markdown es una convención de escritura. No tiene DOM, ni manejadores de eventos, ni formularios, ni esquema de metadatos más allá del frontmatter que añadan los usuarios. Está más cerca de una taquigrafía que de un lenguaje de marcado. Cuando pasas Markdown por un parser, la salida suele ser HTML, pero Markdown solo se preocupa por las partes de un documento que un escritor teclea a mano: encabezados, párrafos, énfasis, listas, enlaces, imágenes y código.

Esa diferencia determina dónde vive cada formato:

TareaMarkdownHTML
Escribir un primer borradorRápido, legible en cualquier editorVerboso, interrumpe el flujo
Diferencias en control de versionesLimpias, a nivel de oraciónRuidosas por las etiquetas
Diseño precisoDébil por diseñoFuerte
InteractividadNingunaNativa
EstilosDelegada al renderizadorEn línea o con CSS

HTML es la página final. Markdown es el manuscrito.

Por qué se extendió tan rápido

Tres fuerzas impulsaron a Markdown desde un script de Perl de nicho hasta el lenguaje predeterminado de la escritura técnica.

Control de versiones. A medida que Git se volvió estándar, los desarrolladores comenzaron a guardar la documentación junto al código. El texto plano ganó porque las diferencias eran legibles. HTML y los documentos de Word convierten pequeñas ediciones en bloques ilegibles en un diff. Markdown se mantuvo legible.

GitHub. En 2009, GitHub comenzó a renderizar archivos README.md en las páginas de repositorio. De repente, cada proyecto necesitaba un archivo de Markdown. Stack Overflow siguió con Markdown para preguntas y respuestas. Los desarrolladores aprendieron la sintaxis porque las plataformas que usaban a diario la requerían.

Generadores de sitios estáticos. Herramientas como Jekyll, Hugo, Gatsby y más tarde Next.js convirtieron archivos Markdown en sitios web completos. Los escritores podían publicar sin un CMS. Los archivos fuente vivían en un repositorio de Git y un paso de compilación generaba HTML. Ese flujo de trabajo, ahora llamado docs-as-code, convirtió a Markdown en el formato de entrada para una gran porción de la web moderna.

Las aplicaciones de notas dieron el empujón final. Obsidian, Notion, Bear, Logseq e iA Writer admiten Markdown o un derivado cercano. El formato escapó de las herramientas de desarrollo y se convirtió en una forma de organizar el conocimiento personal.

¿Reemplazará Markdown a docx y PDF?

No. La pregunta surge porque Markdown se siente limpio y los otros formatos se sienten pesados, pero resuelven problemas distintos.

Un archivo .docx es un paquete XML comprimido diseñado para edición enriquecida: cambios rastreados, comentarios, estilos, tablas de contenido, combinación de correspondencia y multimedia incrustada. Es el formato de contratos, informes y manuscritos que necesitan edición de ida y vuelta por usuarios no técnicos.

Un PDF es un formato de papel electrónico de diseño fijo. Conserva fuentes, espaciado y paginación entre dispositivos. Eso es exactamente lo que se quiere para una factura final, un currículum o un artículo académico que deba verse igual en todas partes.

Markdown es un formato de intercambio. Es excelente para redactar, versionar y publicar en la web. Es malo para el diseño de página, la tipografía precisa y la salida lista para impresión. El flujo de trabajo realista es Markdown para escribir y luego conversión a docx o PDF cuando el documento necesita salir del editor de texto.

Ahí es donde los convertidores basados en navegador resultan útiles. Cuando un borrador de Markdown debe convertirse en un PDF compartible, nuestro convertidor de Markdown a PDF maneja la transformación de forma local. Si partes de un PDF y quieres Markdown editable, el convertidor de PDF a Markdown extrae la estructura sin subir tu archivo.

Qué hace bien Markdown y dónde falla

Ventajas

  • Fuente legible. Un archivo Markdown es casi tan limpio como la página renderizada. Puedes leerlo en una terminal, un cliente de correo o una aplicación de notas del teléfono.
  • Portátil. Es texto plano. Ningún proveedor propietario, ninguna licencia, ningún formato binario que corromperse.
  • Amigable con diff. Git puede mostrar exactamente qué oración cambió. Escritores y revisores se benefician de inmediato.
  • Con muchas herramientas. Cada lenguaje de programación tiene parsers. Cada plataforma importante tiene editores.
  • Nativo de la web. Se compila a HTML, el formato de salida real de la web.

Limitaciones

  • Especificación ambigua. La especificación original de Gruber deja casos límite sin definir. Diferentes parsers producen HTML distinto para la misma entrada. Por eso existe CommonMark, aunque no todas las herramientas lo usan.
  • Sin control de diseño. No puedes posicionar imágenes, definir márgenes de página ni establecer estilos de impresión sin recurrir a HTML o CSS.
  • Caos de sabores. GitHub Flavored Markdown, Pandoc Markdown, MultiMarkdown, Obsidian Markdown y MDX añaden extensiones incompatibles. Un archivo escrito para una herramienta puede renderizarse mal en otra.
  • Tablas y notas al pie son añadidos posteriores. Se admiten mediante extensiones, no mediante la sintaxis principal, y su comportamiento varía.

El resumen honesto es que Markdown es bueno en el 90 % de la escritura que consiste en párrafos, listas, enlaces y código. El 10 % restante lo empuja hacia HTML o formatos especializados.

Markdown en la era de la IA

Si has usado un modelo de lenguaje grande (LLM), has visto Markdown. La mayoría de las interfaces de chat renderizan la salida de los LLM como Markdown de forma predeterminada. Hay razones prácticas para ello.

Primero, Markdown es compacto. Los tokens son costosos y un formato que usa # en lugar de <h1></h1> ahorra espacio. Segundo, Markdown es estructuralmente simple. Los encabezados, listas y bloques de código son fáciles de emitir para un modelo y fáciles de validar para un parser. Tercero, los datos de entrenamiento están llenos de Markdown. GitHub, Stack Overflow, Reddit y sitios de documentación lo usan, por lo que los modelos aprenden la sintaxis de forma fiable.

Más allá de la salida de chat, Markdown se ha convertido en el formato de almacenamiento para sistemas de conocimiento de IA. Las canalizaciones de Retrieval-Augmented Generation (RAG) a menudo dividen documentos en Markdown o texto plano porque la estructura es predecible. Las bases de datos vectoriales, las herramientas de notas y los asistentes de codificación almacenan contexto a largo plazo como archivos Markdown porque los humanos pueden leerlos y las máquinas pueden parsearlos.

El riesgo es la inconsistencia de sabores. Un modelo genera tablas al estilo de GitHub; otro usa HTML para la misma tabla. Una base de conocimiento que mezcla sabores puede romperse al moverse entre herramientas. Estandarizar en CommonMark o en un sabor documentado es la única forma de mantener portable el Markdown generado por IA.

El futuro y la evolución de Markdown

Markdown no se convertirá en un formato más rico. Cada intento de enriquecerlo —tablas, notas al pie, listas de definición, atributos— lo aleja de la misma simplicidad que lo hizo popular. La evolución real ocurre en dos direcciones.

Estandarización. CommonMark, iniciado en 2014, define una especificación de parsing estricta. Cada vez más herramientas lo implementan, lo que reduce la sorpresa de mover un archivo de un parser a otro.

Incrustación. MDX permite a los autores importar componentes de React dentro de Markdown. Los cuadernos de Jupyter mezclan celdas de Markdown con código ejecutable. Los generadores de sitios estáticos tratan Markdown como una fuente de datos para contenido estructurado. En cada caso, Markdown permanece pequeño y la herramienta circundante añade la potencia.

El futuro probable es más de lo mismo: Markdown como formato universal de borrador en texto plano, con convertidores que lo transforman en HTML, PDF, docx, diapositivas o lo que requiera el destino.

Herramientas de lectura y edición por plataforma

No necesitas una aplicación especial para usar Markdown. Cualquier editor de texto sirve. Aun así, algunas herramientas mejoran la experiencia de forma notable.

Windows

  • VS Code con extensiones de Markdown: la opción predeterminada para desarrolladores. Admite previsualizaciones, linting y renderizado con Markdown-it.
  • Typora: un editor minimalista al estilo WYSIWYG que oculta la sintaxis hasta que la necesitas.
  • MarkText: una alternativa de código abierto a Typora con una vista dividida limpia.
  • Notepad++: sirve para ediciones rápidas, con resaltado de sintaxis de Markdown mediante plugins.

macOS

  • iA Writer: enfocado en escritura sin distracciones y control de sintaxis.
  • Bear: una aplicación de notas que usa sintaxis tipo Markdown para la gestión personal del conocimiento.
  • Ulysses: popular entre escritores de formato largo que publican en la web.
  • Marked 2: no es un editor, pero es un potente renderizador de previsualización en vivo para archivos editados en otro lugar.

Linux

  • Ghostwriter: un editor de Markdown sin distracciones con previsualización en vivo.
  • Apostrophe: un editor limpio basado en GTK diseñado para prosa.
  • ReText: un editor sencillo que exporta a varios formatos.
  • Vim / Neovim / Emacs: insuperables para escritores que ya viven en la terminal.

Multiplataforma

  • Obsidian: base de conocimiento local con enlaces, gráficos y plugins.
  • Logseq: outliner que almacena todo como archivos Markdown o Org.
  • Joplin: aplicación de notas de código abierto con cifrado de extremo a extremo y soporte de Markdown.

Bibliotecas de Markdown por lenguaje

Si estás construyendo software que parsea o renderiza Markdown, rara vez necesitas escribir el parser tú mismo. El ecosistema es maduro.

LenguajeBibliotecaNotas
Pythonmarkdown, mistletoe, markdown-it-pymarkdown es la clásica; markdown-it-py es un port compatible con CommonMark
JavaScript / TypeScriptmarked, markdown-it, remark / unifiedremark es parte del ecosistema unified para procesamiento basado en AST
Gogoldmark, blackfridaygoldmark es compatible con CommonMark y extensible
Rustpulldown-cmark, comrakRápidas, seguras, centradas en CommonMark
Rubyredcarpet, kramdownredcarpet es al estilo de GitHub; kramdown es el valor predeterminado de Jekyll
Javacommonmark-java, flexmark-javaflexmark admite muchas extensiones al estilo de Pandoc
C#MarkdigMuy extensible, usada por generadores de sitios estáticos como Statiq

La mayoría de estas bibliotecas manejan bien la sintaxis principal. Las diferencias aparecen en extensiones, rendimiento y qué tan estrictamente siguen CommonMark. Elige según el sabor que necesites soportar, no solo según el lenguaje que uses.

Conclusión

Markdown no ganó porque sea poderoso. Ganó porque no se interpone. Un escritor puede abrir cualquier editor de texto, teclear un documento y confirmarlo en control de versiones sin pensar en formatos de archivo. La compensación es intencional: Markdown renuncia a la precisión de diseño a cambio de portabilidad y legibilidad.

Esa compensación es la razón por la que impulsa READMEs, documentación, sitios estáticos, aplicaciones de notas y ahora la salida de IA. También es la razón por la que seguirá conviviendo con docx y PDF. Cada formato tiene una función. La función de Markdown es ser el punto de partida en texto plano. Cuando necesitas mover ese punto de partida a un formato más rico, un convertidor suele ser el siguiente paso.

Más publicaciones del blog para leer