Mermaid vs PlantUML: cuál sobrevive al contacto con una presentación
Respuesta corta: Mermaid gana en alcance y rapidez — se renderiza de forma nativa en GitHub, GitLab, Notion y Obsidian, y su sintaxis se parece lo bastante a Markdown como para que un compañero edite un diagrama sin aprender ninguna herramienta. PlantUML gana en profundidad — un catálogo de diagramas mucho más amplio, cumplimiento estricto de UML y un control del diseño que aguanta en sistemas realmente grandes. La mayoría de las comparativas se queda ahí. Esta lleva la pregunta un paso más allá: ninguno de los dos anima, y ahí es donde ambos pierden frente a una diapositiva.
La versión honesta de la comparación
PlantUML es un motor Java que lleva más de una década renderizando diagramas. Está más que probado, su catálogo de diagramas es el más amplio de todas las notaciones de texto de uso común, y cubre diagramas de despliegue, diagramas de componentes, máquinas de estados y UML estricto allí donde Mermaid o bien aproxima o bien renuncia.
Mermaid es JavaScript, más reciente y mucho más limitado por diseño. La recompensa de esa limitación es que se renderiza allí donde tu equipo ya escribe. Un bloque `mermaid` delimitado en un README de GitHub se convierte en un diagrama sin paso de compilación, sin servidor y sin plugin. Esa sola propiedad ha hecho más por la adopción de los diagramas como código que cualquier funcionalidad que haya publicado PlantUML.
Así que la pregunta real no es cuál es mejor. Es qué fallo prefieres tener: un diagrama que tus herramientas no pueden expresar, o un diagrama que tu equipo no va a mantener.
¿En qué se diferencian realmente Mermaid y PlantUML?
| | Mermaid | PlantUML | |---|---|---| | Motor | JavaScript, se renderiza en el navegador | Java, normalmente un servidor o un jar local | | Se renderiza de forma nativa en GitHub, Notion y Obsidian | Sí | No, necesita un plugin o una imagen renderizada | | Curva de aprendizaje de la sintaxis | Suave, cercana a Markdown | Más pronunciada, más directivas | | Catálogo de diagramas | Flowchart, secuencia, clases, estados, ER, Gantt, tarta, recorrido y una lista en crecimiento | Más amplio, incluye despliegue, componentes, objetos, temporización y UML estricto | | Control del diseño | Limitado, decide sobre todo el motor | Amplio, con aristas ocultas y posicionamiento explícito | | Comportamiento en diagramas muy grandes | Se degrada, el diseño se vuelve impredecible | Aguanta mejor | | Animación | Ninguna | Ninguna |
La última fila es la que nadie pone en la tabla, y es la que decide qué ocurre cuando el diagrama llega a una diapositiva.
¿Cuándo debería elegir Mermaid?
Elige Mermaid cuando el diagrama viva junto a aquello que describe y lo edite quien edita esa cosa.
Notas de arquitectura en un README, un diagrama de secuencia en una pull request, un flowchart en un documento de diseño, un esbozo ER en una página de Notion. En todos esos casos, el valor del diagrama es proporcional a lo actualizado que esté, y estar al día depende de un coste de edición bajo. El coste de edición de Mermaid es un cambio de texto en el archivo que ya tienes abierto.
Elige Mermaid también cuando el público del código fuente no seas solo tú. Es verosímil que un product manager corrija una etiqueta en un flowchart de Mermaid. Esa misma persona no va a instalar un entorno de ejecución de Java.
¿Cuándo debería elegir PlantUML?
Elige PlantUML cuando el diagrama sea el entregable y no una anotación.
UML formal para una entrega regulada, un diagrama de componentes con una notación concreta obligatoria, una topología de despliegue con cincuenta nodos donde el diseño automático produciría un plato de espaguetis, una máquina de estados con estados compuestos anidados. PlantUML expresa todo esto; Mermaid en su mayor parte no, y forzarlo produce un diagrama peor que elegir la herramienta adecuada.
Elígelo también cuando necesites determinismo en el diseño. PlantUML te da aristas ocultas e indicaciones de posicionamiento que te permiten exigir que un diagrama se vea como lo dibujaste en la pizarra. Mermaid te va a recolocar los elementos, y en un grafo grande eso no es una molestia menor.
¿Qué pasa cuando cualquiera de los dos llega a una presentación?
Este es el fallo que comparten ambas notaciones, y aparece en el momento en que el diagrama sale de la documentación y entra en una presentación.
Ambos renderizan una imagen estática completa. Todos los nodos, todas las aristas, dibujados de una vez. En un README eso es lo correcto — quien lee recorre, amplía y relee a su propio ritmo. En una presentación se invierte: el público recibe la imagen entera en el primer segundo y luego se pasa tu explicación leyendo por delante o, peor, leyendo la esquina equivocada.
Esto se nota cuando eres tú quien habla. Te descubres diciendo «ignorad la parte derecha por ahora», señalando un proyector o repartiendo un diagrama honesto en cuatro diapositivas para poder revelarlo por partes. Ese último apaño es el caro, porque ahora un cambio en el sistema significa editar cuatro diapositivas que ya se han separado del original.
Ni Mermaid ni PlantUML tienen respuesta. Mermaid arrastra desde hace años peticiones abiertas de diagramas animados. PlantUML nunca prometió ninguno. Ambos describen estructura, y una presentación necesita secuencia.
El lado del formato lo tratamos en Mermaid a PowerPoint, y el lado de la presentación en cómo presentar la arquitectura de un sistema.
La tercera opción: conserva el texto, añade la secuencia
No tienes por qué elegir entre los diagramas como código y un diagrama presentable.
El conversor de Mermaid de FluxDiagram lee cualquiera de las dos notaciones — definiciones de flowchart, secuencia, clases, Gantt y tarta de Mermaid, y bloques `@startuml` de PlantUML —, extrae los nodos y las aristas, y genera una versión animada que se construye en la dirección de flujo que tu código ya declara. Expórtalo como GIF, MP4 o WebM e incrústalo en PowerPoint, Google Slides o Keynote.
La propiedad que importa: tu definición se queda donde vive, en el repositorio, sujeta a revisión, junto al código. La diapositiva recibe un artefacto generado en lugar de una captura de pantalla que empieza a quedarse obsoleta de inmediato. Cuando el sistema cambia, cambias el texto, como ya haces, y vuelves a generar.
Eso replantea la pregunta de Mermaid frente a PlantUML. Ambos funcionan como entrada. Así que elige según los criterios de arriba — alcance y coste de edición frente a catálogo y control del diseño — y no según cuál quedará mejor en la presentación, porque ninguno lo hará, y ninguno tiene por qué. Nuestra comparativa más amplia de herramientas está en FluxDiagram frente a las alternativas.
Preguntas frecuentes
¿Puedo usar Mermaid y PlantUML en el mismo proyecto?
Sí, y muchos equipos lo hacen. Un reparto habitual es Mermaid para todo lo que se renderiza en el README o el wiki, y PlantUML para documentos de diseño formales que de todos modos se exportan. El coste son dos sintaxis en la cabeza del equipo, así que poneos de acuerdo sobre cuál vive dónde y dejadlo por escrito.
¿Es la sintaxis de PlantUML más difícil que la de Mermaid?
Sí, de forma apreciable, aunque no de forma dramática en diagramas sencillos. Un diagrama de secuencia básico en PlantUML y uno básico en Mermaid se parecen. La distancia se ensancha con los skins, las directivas de diseño, los includes y las construcciones UML más estrictas, que es donde reside la potencia de PlantUML.
¿Cuál es mejor concretamente para diagramas de arquitectura?
Para un mapa de servicios pequeño que debe mantenerse al día, Mermaid, porque se renderiza en el repositorio. Para una topología de despliegue grande o cualquier cosa que necesite notación C4 o UML estricto, PlantUML, que tiene bibliotecas consolidadas para ambas. Ninguno se presentará bien como imagen estática; ese es un problema distinto de la elección de notación.
Pruébalo con el diagrama que ya tienes
Sea cual sea la notación en la que escribas, el problema de la presentación es el mismo.
Pega tu código Mermaid o PlantUML en el conversor.
FluxDiagram genera diagramas animados que incrustas en la presentación que ya tienes, en PowerPoint, Google Slides o Keynote.