The author is mixing up two different things: the concept of markdown (text with a little bit of light formatting mixed into it with easy-on-the-eye syntax) and the existing specification of Markdown-with-a-capital-M (and its flow on effects).
The concept is fine. The author may not want to manually write markdown, and may think that no one else wants to either, but they are wrong. It's very very useful to have a way to store formatted text without the horrors of full blown HTML. You can stick some markdown in a CMS database, render it on a webpage, and get the most common formatting: links, bullet points, bold. Great.
On the actual spec/implementation: yes, it's a complete disaster. Especially the way it is kind of mapped on to HTML, so you get weird things like writing "1. blah; \ 1. blah" makes a numbered list with a 1 and a 2.
But mixed in there, the author seems to have some weird assumptions that people are using Markdown primarily to write documentation, and this is somehow Markdown's fault. I genuinely don't understand this, or their point 13 "It’s 2022, we shouldn’t be using ascii-text to write documents."
Clearly we do need something like Markdown, but the existing attempts (including Mediawiki's "wikitext") all reveal that design a markdown syntax looks easy, but is actually extremely difficult to do well.
> On the actual spec/implementation: yes, it's a complete disaster. Especially the way it is kind of mapped on to HTML, so you get weird things like writing "1. blah; \ 1. blah" makes a numbered list with a 1 and a 2.
There is a trade off here though. When people sit down to write something that doesn't have weird edge cases they're not likely to end up with a lightweight markup like Markdown.
So simultaneously the spec may be a complete disaster and a contributing factor Markdown's success. Much like how the human brain is very bad at adding numbers together and has so far effortlessly out-competed alternative species that had brains that were great at numbers but not vision processing (being great at adding numbers is so useless for an animal I assume the skill never evolved, but imagine there was a creature somewhere with amazing additive powers for the sake of argument).
Having an unambiguous spec could theoretically be a disadvantage to adoption outside of a very carefully designed markup.
I've heard very similar arguments, for Perl, a couple of decades ago.
And yeah, it's not entirely wrong. Perl was useful, too.
But I desperately want the thing that is for markdown what modern JavaScript, Python and Go have become for Perl.
I want a markup language that supports the most basic things, looks reasonable on the eyes in un-rendered form (so we don't need terrible rich text editors everywhere), and is very friendly to being embedded in bigger documents of its own type or plaintext. It should be possible to have that with a proper, unambiguous (both for humans and for computers) spec.
reStructuredText met a lot of what you are looking for in that "modern" markup language, though reStructuredText doesn't have much of a life outside of the Python ecosystem still.
For their major gripe that point 13 is a pretty weak one. Text editors can present a Markdown document any way you want, and even a WYSIWYG editor is possible if you like that.
Besides, Markdown fully supports alternate character encodings, not just ASCII (that would make Markdown really obsolete). Most people surely use UTF-8 for Markdown documents.
> Clearly we do need something like Markdown, but the existing attempts (including Mediawiki's "wikitext") all reveal that design a markdown syntax looks easy, but is actually extremely difficult to do well.
Related to that, there's also an obvious "network effect" at play here. Every Mediawiki uses "wikitext" so to use Mediawiki you learn "wikitext". As a user you don't want to have to learn more than one of these syntaxes so you use whatever is most common. I think that's the tautological answer to headlining question "Why Is Markdown Popular?" network effects, specifically "Markdown is increasingly popular because Markdown is already popular". It's used in enough places and has to be learned by enough people that generally people learn Markdown. Once they've learned Markdown they expect to use it everywhere else (and so Markdown spreads).
(I had a time where I preferred reStructuredText and its increased power and capability and internal consistency over Markdown. At this point because of network effects, I've decided to just focus on Markdown like "everyone else", though.)
I came to the same conclusion years ago and made myself and "alternate" markdown-like format that superficially looks the same, but has a grammar compatible with parser generators like ANTLR.
Took me about a week to produce something that could generate a nice document object model, and spit out HTML (or anything you please).
The concept is powerful. The specific Markdown implementation however is too messy for proper tooling.
No, it is specifically markup which tries to be nice to read even unrendered. Reading HTML source code is rarely nice and that is also a form of markup language.
This wikipedia page includes reference to WhatsApp... Should it?
I understand that you can use bold, italic, underline, but that is where the comparison ends - the answer to Features is "No" in the comparison table versus others. Not all other comparisons include it.
It's almost as if someone shoe-horned it in for greater visibility. "Hey look at our app, it's better than competitors because it's listed here!" Yet it's competitors offer the same or more.
The article actually fails to answer the question in the title. It's a long list of reasons the author believes it should not be popular. But it clearly is massively popular. So maybe there's something wrong with his line of reasoning?
Anyway, Markdown emerged out of the Ruby community. So it's not strange that there is no specification. Ruby is a dynamically typed language so, ruby programmers tend to not specify a lot of things like types or schemas. And indeed the Ruby language it self is a bit under-specified. The spec is simply "whatever ruby does is what it does", which sucks for alternate implementations like JRuby. The same is true for Markdown. Whatever the original markdown library does was the spec. And it has since been loosely implemented by others doing their own Markdown derivatives. Like the widely used Github flavor. Which is also a ruby based implementation, I think. So it is similarly under specified.
However, the lack of a specification is not much of an issue since markdown is used by humans to be turned into something human readable with some html formatting. Either it's readable or you fix it. And it's simple enough that any markup typos in markdown are usually not that big of a deal. The main goal of Markdown is to get out of the user's way so they can focus on content rather than formatting.
As for editors. There are plenty of editors that support markdown. Many of them even have live previews. So, it's great for that.
The concept is fine. The author may not want to manually write markdown, and may think that no one else wants to either, but they are wrong. It's very very useful to have a way to store formatted text without the horrors of full blown HTML. You can stick some markdown in a CMS database, render it on a webpage, and get the most common formatting: links, bullet points, bold. Great.
On the actual spec/implementation: yes, it's a complete disaster. Especially the way it is kind of mapped on to HTML, so you get weird things like writing "1. blah; \ 1. blah" makes a numbered list with a 1 and a 2.
But mixed in there, the author seems to have some weird assumptions that people are using Markdown primarily to write documentation, and this is somehow Markdown's fault. I genuinely don't understand this, or their point 13 "It’s 2022, we shouldn’t be using ascii-text to write documents."
Clearly we do need something like Markdown, but the existing attempts (including Mediawiki's "wikitext") all reveal that design a markdown syntax looks easy, but is actually extremely difficult to do well.