alt Hacker NewsWhy are we still using Markdown?
Comments
The article talks about how confusing Markdown can get. I understand, but HTML is *much* more confusing when it comes to creating technical articles. These days we are going to see more and more markdown with the advent of AI. Markdown works really we with AI because it reduces the number of tokens required for the same amount of information vs HTML.
i use it because it does what i want and is easy to use.
For me, one major issue with md is that it does not support indentation that could be used for collapsing sections.
Most md editors don't support collapsing or folding sections, even though they could. VSCode had this feature where indentation is used as a simple hint to support collapsible sections, but md treats indentation as a code hint.
Markdown is _fine_? I certainly have my own issues with it; most of which can be mitigated by adhering to a style guide (e.g. only use one syntax for <em> and <strong> as well as <ul> and headers). I'm not sure why we need both asterisks and underscores to represent the __same semantics__ – to me this feels wasteful of precious ASCII. Perhaps it was to allow the writer to express their preference while providing a shared and consistent meaning (same with the other duplicate forms). In that sense it seems to have done an <del>excellent</del> okay job at affirming common ground. I'm not sure. From what I can tell, the original author has been reluctant to do the work here and has left this for others (i.e. CommonMark).
I do love writing in Markdown, but my reasons are adjacent in some ways. It's a flat file, the syntax is easy to on-board new users with, adoption is widespread, and the HTML escape hatch is available. I only adhere to the syntax because I can usually expect a parser to exist for whatever environment I'm in.
I don't think this is the best we can do (or have done). I find myself conflicted about where to go next. Gemtext is nice! Except, what I often want is more expressiveness and consistency. This will probably be, for me, a spec that can still be run through a "reasonable" Markdown parser. When the output breaks, it still comes out as readable plain text (albeit with some weird ASCII scattered through my prose).
I was lamenting the other day that we used to have SGML SHORTREF, then XML came along because supposedly SGML is just too hard to parse. But XML is for computers, not for humans. So then we got Markdown, which is worse than where we started from.
There are other options. AsciiDoc come to mind.
If we're going to define a programming language as one that is Turing complete, it's important (in a kind of pedantic sense) to note that that includes HTML (with CSS), which can be used to encode a Rule 110 automaton, and excludes C, whose standard imposes an (implementation-defined) upper bound on accessible memory, meaning it can never, even in principle†, similarly a Turing machine, which has infinite storage. This is probably not what was intended :)
† Obviously, for physical reasons given our current understanding of cosmology, no _implementation_ of a language can ever really be Turing-complete, but some language definitions are theoretically compatible with Turing-completeness, and others aren't.
Markdown is widely used but I agree that it's a mess, there are so many dialects..
A similar but better markup is ASCIIDOC; it's formally defined and comes with a Technology Compatiblity Kit (TCK) that can be used to certify the compliance of an implementation with the spec.
I've thought about this a bit too, and instead of a straight escape hatch to html when any special formatting is necessary, it might make sense to bind css to particular elements like so:
##[color:red] Heading 2
or using code blocks with particular headers which render out as normal text with the styling applied, like this:
```styling: 'ruleset here...' Lorem Ipsum Dolor ```
this does require a lot of work to consider what might be ergonomic for a particular element (by element I mean ATX headings, blocks, etc.), though.
I strongly dislike flexible input like __Unambiguous___, *Unambiguous*
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
The Pandoc Markdown dialect solves many of the mentioned issues. If you want a good editor for that have a look at
In a few years we'll all laugh at how ridiculous this blog post is.
If we are still using XML/YAML/JSON etc despite all their faults and shortcomings, Markdown can (and will) last decades.
This is why John MacFarlane designed djot https://djot.net/
Markdown is much easier to write quickly than HTML. Situations where I write Markdown quickly include writing messages on Slack and for AI chatbots. I wouldn't want to use HTML in either of those cases.
> The real issue is that to ship a Markdown parser you also need a to ship a friendly HTML parser.
I’ve never attempted a markdown parser let alone any parser, so pardon me for asking a stupid question: doesn’t the markdown parser just let through HTML? Why does a markdown parser need to parse html?
Bonus points for MD being readable even when it's not parsed. More bonus points for Sublime Text displaying it in plain text and still looking great. Good enough++
The only changes I'd want to Markdown:
- Reverse the link syntax braces, so the URL is in [], and the link text is in ()
- Allow table cell content to have line continuations
I think markdown has problems, but this doesn't really propose a sane solution.
The need markdown solves is document formatting without needing to know or use a tag-based markup language and remaining easily human readable and editable.
That said, this is actually not the most widespread requirement. And when people need to solve this requirement, there often not tons of options. So some flavor of markdown is often the least problematic option.
We're not "still" using Markdown, we're only getting started.
Markdown is only going to get more popular as AI agents usage grows.
Easy and "good enough" very often trumps complex and comprehensive. Markdown is great precisely because it can't do a lot of things.
i would not use html(5). XHTML? perhaps. but try to find 3 parsers, which parse html in the same way and not segfaulting.
It's not possible. HTML is worse. You need at least something, which on parsing does not segfault.
The answer to the question in the headline:
- It's pretty easy for humans to read & write
- It's very easy for AI to read & write
- It's quite token-efficient relative to its expressiveness
- It can be used in many different contexts, so it's actually surprisingly good for interchange.
There are many formats that are better-suited for a given purpose, but Markdown remains a very attractive compromise for many applications.
I rarely render it and only use it with syntax highlighting in my text editor, and that’s it. It helps structure my notes, and I love it, KISS.
Markdown is for us humans. HTML is for machines.
Per keyboard stroke, you write much more content with MD than HTML.
Even without a specific browser/reader Markdown is relatively non-intrusive to read. You cant read HTML without an extra tool/effort to discard tags.
And you can parse MD with regular expressions, or can you? ;). (tip hat to infamous Stackoverflow discussion)
Because I think it’s fair to say it’s becoming a standard format for ai agent specs docs etc. It’s not going away anytime soon.
Markdown is essentially plain text with a couple extra features. I think Markdown’s basic appeal is that it’s plain text.
Start with Obsidian (with "Live Preview" and "Editing Mode" as defaults) for fantastic WYSIWYG note-taking. Then layer in plugins like Outliner, Templater, Canvas, Relay... and realize Obsidian is almost like an OS for .md files -- which are portable, and easily human- and machine-readable.
This sounds like all the arguments against using JSON/YAML as well.
People forget how important good UX can be, sometimes.
We're using Markdown, YAML, and JSON bc they're easy to use; they're "highly memetic" (easy to learn, easy to teach, easy to spread)
They don't require many months to learn like XML, back in the day
I just can't find myself summoning the energy to be mad about markdown. It's good enough for like 99% of the things I use it for. Sometimes I get annoyed at specific extension support or whatever when I realize I shouldn't be using markdown for that task.
I'll give them credit for not just being another "markdown sucks, let's switch to RST" slop article. Even more so as they say they don't have a solution - because a solution would be like asking for 3/3 on "cheap, reliable, fast" or whatever your favorite version of "engineers are paid to make compromises" is.
Markdown is great at small-to-medium documents; LLMs seem to like it too possibly out of a combination of fairly logical design and lots of training examples.
Custom extensions like |||warning\nDisconnect from the internet befor trying this!\n||| get you a bit further and don't tie you into HTML.
The moment you need multiparagraph items including code blocks inside a numbered list that also has an unnumbered list child of which some of the items are images ... the person who set you that task probably doesn't understand good design, but regardless, I find you need something with an explicit tree structure, that is there are markers for both the start and end of each node such as <td> ... </td>. That necessarily makes the document harder to write, though at that complexity it'll probably be hard to read too.
i like html fine, but org-mode, now you're talkin'. it's like the nasa voyager equivalent of text markup. just needs to be rescued from being held hostage in emacs.
Because Markdown is awesome, easier to write, and easier to read at the source level.
Just write in whatever language makes you happy. Nobody is forcing you to use markdown
Because there's only one reasonable implementation of AsciiDoc
Markdown lacks JavaScript and can be considered mostly harmless.
He at least admitted to be a simple monkey brained developer.
Textile was better, but less popular IIRC
Why aren't you quietly stop using Markdown?
Anyone that thinks Markdown is bad is crazy. People need to be able to quickly and easily markup their text.
I'd like to see a less flexible markdown standard. There's no reason to have 2 different ways of italics/bold etc. Pick one, reject other text.
Markdown has a lot of weird choices and works best for longer documents.
Check out my "Advent of Markdown" where I go through surprising markdown behavior: https://mastodon.social/@timokoesters/115643467322561173
Because it supports HTML as an escape hatch.
I think the author is missing the point. Markdown is easy for humans to read, write, and modify. Yes, parsers can be complicated. Few people need to write parsers, so that's ok, if unfortunate for those parser authors. Orders of magnitude more people need to read, write, and modify the documents themselves, and the fact that it's easy to do so is a huge strength.
HTML is terrible when you consider these properties. It's not easy to read, and is annoying to write and modify. Ditto for any other XML-based markup language, or even something like RST. LaTeX is right out.
Ultimately the author seems to suggest plain text should be what people use? That misses the point. Plain text is great for a lot of things, but if you're going to generate HTML (or something else) from it, you need something that at least has some structure. Markdown hits a nice sweet spot where it has enough structure such that you can reasonably generate rich-text document formats from it, but not so much that non-technical users can't work their heads around the format.
Clickbait
This website, at least in dark mode, doesn't have any visible indication when text is selected.
... Which is additionally frustrating, since the links at the bottom aren't actually links (so you have to select them to copy and paste into your address bar)
Funniest part of this article is claiming * will produce a b tag then demonstrating it will usually produce a strong tag and not even noticing this.
> These 2 produce IDENTICAL output.
...and? What a weird article. Of course two different pieces source code can produce identical output. Every single mainstream languages are like that too.
This article is legit, but markdown is good enough to me. Actually, I was using reStructuredText which has a better specification for writing. I switched back to Markdown because its syntax is easier to remember and fulfill most of my needs. The thing I needed was comments for adding folding marks in vim. I use inline <!-- --> to do so and that's OK.