Recently, someone shared an article with me from the team of iA Writer. I have read it shortly after its initial publication at the end of March, but it has been re-suggested to me multiple times since then. It is titled “Markdown and the slow fade of the formatting fetish.” The article is pretty long, but can be summarized quickly. First, Markdown is gaining popularity, as indicated by the fact that more and more software we interact with daily support it (including WhatsApp, Discord, and generative AI chatbots). Second, opposed to Markdown are proprietary formats, and the article makes the case that Microsoft has been especially egregious in “locking in” users with Word. Third, switching fully to Markdown is the way forward.
Given that the article seems to resonate with readers, it seems worthwhile to pause and ponder on its premise, and how it portrays the evolution of Markdown over the past two decades. Naturally, the team of an application that makes money with a Markdown editor, can be assumed to be biased. I do share their sentiment that proprietary formats, and Microsoft Word especially, should be a thing of the past, and that Markdown offers undeniable benefits for professional writers.
However, I believe the article misses the broader societal developments that have happened over the past 20 years, and I do not share their optimism. Again, I do believe this to be caused by bias, but I also think it is great to reflect upon my own stance towards Markdown, too, now that I have been in the game for about a decade, too. In the following, I will make the case that Markdown’s continued success is inhibited by four blockers. I argue that, unless developers of Markdown software actively work towards better support for professional use-cases, standardization, and tooling support, Markdown will remain at the level of everyday usage, and is unlikely to increase its visibility going forward.
The Premise: Professional Markdown in the Last Decade
Before I start, let me add the disclaimer that I am naturally also biased, so take the following paragraphs with a grain of salt. As the main developer of Zettlr, yet another Markdown editor, I may not make money with promoting Markdown, but I probably wouldn’t continue developing such a Markdown editor if I did not believe in its potential. However, I did keep an open mind towards how users actually write. And I think this is the primary critique I have towards that article.
Back in 2017, when I started developing Zettlr, Markdown support was dire. WhatsApp had already introduced a mutilated form of Markdown syntax for some quick formatting in messages, and there were plenty of small, independent projects that utilized Markdown syntax. But nobody really knew what Markdown actually was. And nobody cared.
To me, Markdown offered two primary benefits over more complex Word processing formats. First, it separates layout from writing, which I identified as a big issue especially for me. I could spend hours re-layouting my essays before finally submitting them. Second, it is much simpler and more versatile. Since the format itself does not consist of zipped folders with many XML files,1 it is much easier to work with Markdown documents at scale. Hundreds of reading notes turn from a daunting mess of individually encapsulated Word files into a batch-processable set of searchable plain-text data.
Isn’t that just … plain good?
Markdown Misconceptions
This leads me to a few things we have to talk about. I believe that especially in the Markdown-space, we have some misconceptions about the benefits and drawbacks of Markdown. These are (1) the universality of Markdown; (2) that all users care about how they write; (3) Markdown is suitable for professional needs; and (4) the ecosystem support for Markdown is qualitatively sufficient and simply needs to be scaled up.
Markdown is not Universal
The first misconception is that Markdown is universal. Surely, you can use Markdown syntax across a bazillion websites and apps. WhatsApp, Discord, Reddit, this blog, static websites, RStudio, Chatbots, GitHub — you name it. Markdown is everywhere. But it’s not universal.
The big problem with Markdown is that it has been developed to solve one use-case, and instead has been used to solve hundreds of completely different use-cases. Mind you, Aaron Schwartz and John Gruber have developed Markdown as a solution to writing proper emails. Which email program do you know that actually allows you to use Markdown to compose emails? Likely no one. Most only give you the choice of plain text or rich text. Apple Mail, Outlook, Thunderbird, Gmail: none of these options allow Markdown syntax out of the box. There are some apps that do, but these are either paid, or only support a single provider.
Instead, Markdown has been used to solve a variety of completely different use cases: Comments and discussions on forums and messaging boards, note-taking, technical documentation, and professional text writing. None of these use-cases have been intended by Gruber and Schwartz. And this is evident when looking at how apps implement Markdown.
Here’s an incomplete list of deviations from the standard Markdown syntax that I can name off the top of my head: (a) Obsidian uses a non-standard ![[]]-syntax to link images from across your loaded folders; (b) Zettlr and Pandoc use the non-standard citation syntax @citekeyYear; (c) some apps use !!! note for admonitions; (d) GitHub uses > [!NOTE] to the same effect; (e) and even if you’d like to call Wiki links ([[link]]) “standard,” there is disagreement about whether titles should come before or after the link target ([[link|title]] vs [[title|link]]).
There’s much more. Every app that wants to support some specific use-case has to invent some syntax ex nihilo. Markdown standardization is so difficult that even John McFarlane, creator of Pandoc and the CommonMark specification, has given up trying to create a comprehensive standard, and instead just calls it a baseline. There is pandoc-crossref, pandoc supports three different types of tables (pipe, grid, and “simple”), and a litany of custom elements scattered across the ecosystem. Some are slowly adopted across the ecosystem as de facto standards, such as footnotes or ==highlights==, but this blog, for example, still does not support either natively.2
We may convince ourselves that, once you know Markdown, you can easily switch between programs, but the reality is that you will have to re-learn some aspects of Markdown every time you do switch. Even though there is no strict vendor lock-in because it’s all just plain syntax: if you have no experience with whichever Markdown editor has created some file, you will find syntactic elements whose purpose doesn’t immediately become clear to you.
In essence, Markdown applications have re-created a very similar problem as they set out to solve twenty years ago. Users who use some application have less and less incentive to switch apps as they continue to use it, because it becomes more and more difficult to exchange the custom syntactic elements between apps. Markdown syntax and the apps which produce it have become less interchangeable over time.
Don’t get me wrong: I still believe that the benefits of Markdown far outweigh its drawbacks. But Markdown is far from universal beyond a very small set of agreed-upon syntactic elements.
Users Don’t Care About Markdown
This brings me to the next point: Users don’t care about Markdown as much as us creators of Markdown apps tend to believe. Yes, it feels bad if you set out to create some “Markdown Editor for the 21st century” and then some random dude comes around and demands a WYSIWYG-editor. But is the user in the wrong? Or is it rather that you have made Markdown a part of your identity?
The reason that Markdown is so universal is that, in many respects, a few simple syntactic elements can make messaging and commenting easier. One can securely support bold and italic text with a few additional parsing rules — no need for a complex visual editor. But as soon as you require more complex elements, the question becomes: Wouldn’t a visual editor be simpler? Sure, editing code satisfies some niche urge to maintain “purity,” where there is not a single superfluous character in your documents. But apart from that, the efficiency of whichever writing solution you have should be dictated by the use-case, not the syntax. Sometimes, a graphical editor is just simpler than adding Markdown support. Even Wikipedia now defaults to a visual editor, because it is just simpler than learning the MediaWiki syntax.
While each app has a small subset of users who use the app primarily because of the ability to write Markdown, the vast majority of users use it because it makes their lives easier. Because it provides functionality other apps don’t. And if it would work without Markdown, many of those wouldn’t be sad. Markdown is not a silver bullet, and users know that. Over the past ten years developing a Markdown editor, I have realized that users are very smart when it comes to understanding their needs. If a user switches to Zettlr, they usually have plenty of experience with rich text editors, and are looking for an alternative not because it uses Markdown, but because it makes citing, writing papers, and collecting research notes easier.
However, let me add to this that I believe users would care more about Markdown if a few show-stoppers would be removed. Since we all are still heavily indebted to Schwartz and Gruber, I feel we, the developers, are a bit hesitant to transform Markdown from its original use-case to a truly capable markup language. In the end, we are missing two crucial things to make Markdown actually useful to users: some added syntactic complexity, and heavy improvements in tooling.
Markdown Cannot Satisfy Professional Needs
Let me begin with the first of these missing things with Markdown. It cannot fully cater to professional needs. One of the reasons that there are so many custom elements is that, to satisfy professional needs, we need professional syntax. A great example is the citation- and crossref-syntax from Pandoc. Citations are indispensable tools for academics and other professionals, and as such, first-class support in Markdown is a simple necessity.
But which editors actually support citations? There’s Pandoc and Zettlr, maybe Quarto and RStudio. These are the only apps I can think of that support the syntax natively. Others, including VS Code, Obsidian, and others, support it via plugins. But the vast majority of Markdown apps don’t support citations at all. And, since citations are not considered standard Markdown, nobody can really complain. But this makes the vast majority of apps difficult to use for academics.
However, it is not as simple as making Markdown Turing complete. If we turned Markdown into something very customizable for professional needs, we would end up with a second incarnation of LaTeX. Do we want that? Not if every Markdown app under the sun (including me) doubles down on the fact that Markdown is so much simpler than LaTeX.
No, what I believe Markdown requires for even broader adoption is a combination of two things: Further syntax standards, and improvements in tooling.
On the one hand, we need to improve the syntax by standardizing crucial elements such as citations, Wiki links, and some features that Pandoc has added. We need to go beyond the existing minimal consensus of Markdown syntax and enable additions in a less haphazard way as they are currently done. Instead of leaving every app developer to their own devices when it comes to supporting additional elements, it might make sense to standardize syntax for specific use-cases, and enforce wide ecosystem support.
Think about it: How does “CommonMark for Academia” sound? Or “CommonMark for technical documentation”? This would mean that we still have to learn a new set of elements whenever we switch contexts. There would still be specialized syntactic elements for specific use-cases. But it would mean that there is only one set of specific syntax per use-case. This gives users certainty that they know which elements they can use in a given app, and give app developers a standard to implement. In addition, it would make communication simpler. It would be easy to spot whether an app is useful for you as a user (“This app implements Academic CommonMark”), because you know what you need it for.
But more specialized and formalized syntax is only one ingredient if we don’t want to create a second LaTeX incarnation. Instead, we need to improve tooling. Because it is one thing to offer some syntax for a certain use case, but a completely different one to make the feature usable for end users. And if we don’t want to encode all benefits in the Markdown syntax, this functionality has to come from the application ecosystem.
Wide Adoption Requires Better Tooling
This leads me to the last point I wish to make. A final misconception we have towards Markdown is that the current ecosystem support for Markdown is qualitatively sufficient and simply needs to be quantitatively scaled up. To the contrary, I believe that many tools remain stuck in plain Markdown land.
I feel that many tools are too less opinionated for many professional use-cases. Take, for example Obsidian and VS Code. Both are often mentioned when it comes to alternatives to Zettlr. Or more simple tools, such as Joplin and Nextcloud Notes. None of them cater to professional needs by default. Footnotes, highlights, exports, or the support for journal and conference templates can sometimes be added by installing plugins. This works for many people, but I have also seen complaints that it adds clutter. Also, plugins usually mean that there are multiple alternatives for the same functionality, making it more difficult for users to decide which plugin serves their need better. Lastly, plugins have a specific UX that will always remain secondary for ease of use. There is a big difference in experience when you can add a bibliography file using the app’s UI versus when you need to edit a configuration file.
But a better example for my point is collaboration. I want to share a story from a few years back. Sometime in the late 2010s, I was asked to write an opinion piece for a UK outlet. And they asked me to submit a Word file — which makes sense, given that most people back then probably didn’t know what Markdown even was. But everyone had Word installed. So I went and wrote the article in Zettlr, exported it to Word, and sent it to the magazine.
A few days later, I received an email indicating that their review is now done, and I should approve the article proof before publication. So they sent me a Google Docs link (because that’s the simplest way to collaborate in real time on documents).
And would you believe it? They converted my Word file to Markdown. The email contained a lengthy explanation on what Markdown is and that they used it on their website.
Whenever I think about this story, I chuckle, because it is such a powerful demonstration of the absurdity of everything Markdown. Whenever we have to work with many people, we have to use something everyone intrinsically understands, which is Microsoft Word, ideally with added real time collaboration, which is Google Docs.
This is where Markdown still lags behind. There is simply no proper equivalent to Overleaf for Markdown. Real-time collaboration with a “Track Changes” feature is simply not available. And it is precisely this lack of corporate features that will for the foreseeable future keep Markdown from actual wide adoption.
Now, of course there are services that allow collaboration with Markdown. There are ways around it. There are initiatives such as CriticMarkup. But none of this is widely supported. Collaborative Markdown services usually lack dozens of features the Desktop-apps support. And CriticMarkup, while a great initiative, has never been adopted, because most apps focus on the individual, not teams.
Long story short: in the professional space, we need both better support for professional use-cases per se, and better support for the collaborative team-structures that typically come along with professional work. And this is a qualitative issue, not one of simple scaling. Without these initiatives, we will forever remain stuck in the current state where many people still don’t know what Markdown is.
Final Thoughts
I like seeing articles that hold up the flag of Markdown, and which are very optimistic about the power of Markdown. But I also believe that this mindset can induce some misconceptions that remove us application developers from the users. Yes, we all have our devout Markdown-supporters who use an app because of the Markdown. But we are well-advised not missing out on the variety of the users we hope to have, because we focus too much on Markdown, and too little on what users actually need.
Indeed, it is nice that iA Writer apparently didn’t change its layout for 15 years. But in those 15 years, we have received massive improvements on Google Docs, we got Overleaf, and the industry has simply moved on. Not implementing additional features on top of the Markdown core seems more and more like the behavior we would expect from a hermit who leaves civilization because they don’t need all the new things that culture generates.
In short, if Markdown applications do not embrace the needs of their users, and instead cling to the assumed “purity” of plain Markdown syntax, they will lose out in the long term.
1 I will never grow tired of recommending you to take a .docx-file, rename it so that its filename ending is .zip, unzip it, and then take a look at the glory mess that is the DOCX-format.
2 If you’re interested, there’s a big bunch of ugly regular expressions in the backend that facilitate footnotes for this blog. I raised an issue with the maintainers two years ago.