...but it's delicious that this blog post also demonstrates an ambiguity in Markdown: how to handle intra-word emphasis. In the rendered output, "mark_up_" and "mark_down_" were probably intended to be "mark<em>up</em>" and "mark<em>down</em>", but the underscores were instead rendered literally.
I do appreciate that Markdown's solution to ambiguities like this is dead simple - just inline some HTML.
It wouldn't even make sense for markdown if it were language-agnostic to output <em> when that's HTML-only.
I'm going to go to my grave repeating that <em> is just <i> version 2.
<mild> and <strong>, or <em> and <emem> (or <double-em>, or <very-em>) might have been clearer, but at this point we'll never know.
Edit: apparently <i> has been redefined to be "the idiomatic text element" rather than just italic - so perhaps it's a semantically appropriate choice here after all! https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Emphasis/italics is using /
When markdown emerged, docbook was getting even more elaborate, and vendors everywhere had for decades been locking people into frameworks and languages with fantastic features that were hard to use -- and then the internet bubble had popped. Then people realized they'd thrown away years building complex system, and had little tolerance for promises.
Markdown is something you can use in its native form. It's both source and destination, with a touch of future-proofing: if the opportunity arrives, you can polish it into anything, and mostly parse it yourself.
(What's surprising to me is that pandoc barely registers when compared with markdown on google trends since 2004; pandoc is the reason I switched completely to markdown in ~2010)
If I imagine beginner-coding me, the first thing I would ask for example is why the hell not just use html by that point. Markdown is a thing I could peesent my non-technical parents unrendered and they still would be able to read the content, just fine for the most part. Try that with docbook.
Now nerds like to pretend the more powerful format is automatically superior. It isn't. Markdown is sucessful because it is so barebones and opinionated and because it forces a focus on the content over formatting. If that is what you need markdown is perfect. If it isn't, go for Latex, HTML+CSS, Typst or use InDesign or whatnot.
Markdown is the opposite of opinionated; nearly everything in the original spec can be done in more than one way. There’s two separate syntaxes to do headers, links, italics, bold, and three ways to do unordered lists.
https://keenwrite.com/blog/2025/09/08/feature-matrix/
I wrote the feature matrix to objectively compare plain text-based documentation formats. How do DocBook's features compare against Markdown?
Word today is a ghastly, incompetent shitshow.
I don't really know. I wasn't around back then to watch it unfold. But I still much prefer org mode due to better emacs support and (IMO) more intuitive syntax for things.
As someone who now uses both, I think the syntax between the two is really kind of a wash. I know Org Mode folks who insist that its syntax for links is more intuitive than Markdown's, for instance, whereas I used to insist that Markdown's was. Now I think neither is really intuitive -- the one that feels more natural to you is, very likely, the first one you learned and got comfortable with. Beyond that, most of the differences in syntax are kind of academic. (I would genuinely argue that Markdown's block quote formatting, which is the way that plain text email tended to quote messages, is more intuitive, at least to anyone who remembers writing email in plain text.) Org Mode partisans also correctly point out that you never have to worry about differences in syntax parsing the way you technically do with different flavors of Markdown, but I'd argue that's because there's effectively only one Org Mode parser out there, e.g., Org Mode in Emacs. There is no formal syntax specification for Org Mode any more than there is for Markdown, and if Org Mode had become as popular and had as many different implementations in as many different programming languages, it would absolutely have the same issue. (In fact, the few non-Emacs Org Mode parsers that I've seen are, to a one, at significant variance with Original Flavor Org Mode once you get past the basics.)
Org Mode's real strength isn't the syntax, it's everything else. I don't use it for GTD, either, but I use it as a task manager and an agenda system for work, and as a personal journal and fiction outliner. None of the power it gets for any of those things comes from using asterisks instead of hash marks for headlines, or slashes instead of underlines for italics. :)
I have not been able to get markdown to walk in Vim, anywhere near as well.
Orgmode text is fairly well supported now, across a plethora of non-Emacs apps and editors. I've enumerated several in my post [0].
Quoting oneself...
> But seriously, Emacs winkwink, amirite?
> Utility is contextual, remember? > > So here are ways to use org-mode without Emacs, for useful-to-you purposes, without even caring it is orgmode text underneath. > > Mobile, Web, and Desktop apps:
mobile: Orgro, a mobile Org Mode file viewer for iOS and Android
mobile: Plain Org, org text view and editor for iOS
mobile: Orgzly, org text viewer and editor for Android (I use this on my phone, and sync notes to my PC with Dropbox).
mobile: beorg for iOS (tasks, projects, notes)
mobile: flathabits, inspired by Atomic Habits, with all your data stored in org files
web+desktop: logseq, a privacy-first, open-source knowledge base
web: organise, web-based org text editor and viewer
web: braintool.org, a Chrome plugin "to easily capture and categorize all the information and knowledge you want to keep track of, right at the point you discover it or create it"
Publish, Import, Export, Parse
More community-enumerated tools for the same
Even Github, Gitlab etc. support org markup these days!
[0] Why and How I use "Org Mode" for my writing and more
When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.
Why didn't you set up an automatic recurring export of your Org files to HTML files that are uploaded somewhere? That's what I did.
Java had a leg-up over C++ by several decades in having a concurrency story (at all) in the language.
I wouldn't use std:: anything for threads even in a greenfield C++ project today.
Garbage collection is more advanced than the primitive management tools available in C++, like smart pointers to reference counted or exclusively owned objects: those approaches are strictly worse than the correct, gold-standard solution to the object lifetime problem.
While sort of technically true, concurrent code expressed in high level language was almost invented in C in the 1980's as the first Unix SMP devices took off (early multiprocessing work at the OS level was at the assembly level, Unix was almost alone in having a portable kernel and the need for SMP).
Java, coming along about a decade later from the same incubation environment, very much reflects that learning. But no, they did it right in Java because they had already done it in C.
Although, Java wasn't really trying to compete with C++ everywhere. It's just that, at the time, C++ was used at all levels. I mean, this was a time when it was C++, Visual Basic, or Turbo Pascal/Delphi for application programming. You couldn't easily get more abstract than that. That's wildly unlike today's landscape.
JSON over XML is more of a "better is better" case, though.
Because almost the entirety of the remaining JSON ecosystem is just duplicating what XML did. We have JSON Path and JSON Query. We have JSON schema. There's even JSLT, although it didn't inherit the flaws of that XSLT library. About the only thing there still seems to be an argument about that XML did is JSON comments.
And, to be clear, JSON's perception as being better performing primarily comes from the fact that web browser developers had a vested interest in making JavaScript engines high performance for ordinary JavaScript, and they spent more effort on that than on their XML libraries simply because it was more important. That means the problem with the web hasn't been the use of XML. It's been the way we stapled half a dozen languages together to do one thing: display a document as a computer interface.
But if you use XML to the minimal level as JSON requires by it's nature, and if XML had gotten the performance interest that JavaScript did, then XML would be fine.
So I don't think JSON is better than XML. I think JSON just got lucky.
"Worse is better" is about simplicity vs expressibility tradeoffs, not an absolute better/worse value judgement. By saying Java is worse than C++ here the OP is only saying that Java is simpler (less expressible) than C++.
Like whether to hide interrupted system calls, or punt the responsibility for restarting them to the application. (That "PC loser-ing problem" example used in the essay).
Between C++ and Java, it is hard call, but I would say that the Java ecosystem values correctness more than C++.
I don't mean valuing the correctness of a delivered application, but valuing the contribution of the language stack to that goal.
Java manages memory, and defines the order of evaluation of operands in an expression. Need we go on? Java also has a security story for loading compiled code. There is no sandbox model of any kind in C++.
> first Java over C++
...really? Java was literally created to fix C++ issues.
> then python and javascript over Java
That's just different, not worse.
> It's strictly worse than its original too.
Tell me more of those exiting stories. I’d like to hear them.
It’s like a microcosm of the burden of code. You publish some Perl script that happens to catch on. It’s good enough; any immediate problems are really trivial. Ten years later though they are annoying. But a new lightweight markup variant? Yeah, we should make it close to compatible with “Markdown” because everyone knows Markdown. Maybe specifically GitHub Markdown. Because if it doesn’t render on GitHub it isn’t real.[1] And so it perpetuates through microgenerations.
- Java is not worse than C++, it's actually better for most large-scale programming
- A (subset) of C++ is still far better for performance-intensive applications (games, low-level systems software, avionics, etc.).
- Related to previous, if you're using ALL of C++ in your projects you're "doing it wrong". It is not a well-designed language.
- I agree that Javascript is a win for "worse is better". Anyone remember Netscape Livewire? I try to avoid that language like the plague, but its runtime support is ubiquitous so it gets the most performance-tuning love.
- Python was, initially, just a better Perl, but its dominance in Scientific computing spilled over into data science. Also, Jupyter notebooks provide a unique value proposition for a FOSS-Mathematica.
Better than Python which also recently started copying over JS decisions, except that Py was easier to use with C libs from the start which made it capture math/data/science usage earlier.
Using JSON for API calls was such a breath of fresh air!
If you have something that’s converting markdown into a rich view and it’s not doing that, the problem isn’t with markdown, it’s with your markdown parser.
Gary Hart?
https://en.wikipedia.org/wiki/Gary_Hart
Yup.
It was a strange time in Democratic politics: The assumption after 9/11 and the success of the GOP in the 2002 midterms was that GWB was going to be reelected in a walk. So not a lot of big names crowding the field.
My favorite Markdown creation was "GistDeck", a bookmarklet that turned a GitHub Gist of Markdown content into a slide show.
So much easier to make and share than a PowerPoint deck.
pandoc -f gfm -t typst -o file.typ file.md
Example: https://daringfireball.net/linked/2026/01/09/moylan.text
... and if you look closely at some of the entries you might spot custom Markdown features that aren't part of the published spec.
It is my assumption that Gruber chose ‘.text’ over ‘.txt’ for several reasons. To give it a little difference when searching for files. To be more legible to non-computer people. And finally, while Classic MacOS did not use file extensions, the Resource Fork type code for text files was ‘TEXT’
> Markdown is a text-to-HTML conversion tool for web writers.
Ergo they’re not Markdown documents, they’re text files that can be converted into HTML using Markdown.
(I personally use “.text” for my own files, and have BBEdit set to use Markdown syntax coloring for that extension, which is why I never saw a need to endorse an official extension.)"
https://daringfireball.net/linked/2014/01/08/markdown-extens...
Chatgpt is pushing markdown to the maximum expose, Google & Microsoft sooner or later should react.
Restructured Text is much more capable, and yet here we are, still using Markdown.
My markdown pages often also have HTML in them, I mainly use Markdown so if I decide some overlong thing I wrote on Reddit actually doesn't suck, I can copy-paste it into a webpage, and my web-server's .smd handler does the convertion. Lowest common denominator. :(
I respect Anil's argument that the extensibility has helped it be adapted to different contexts, and in practice the looseness of it doesn't cause a problem. I do wish CommonMark had more traction (and acceptance and use of the name Markdown). It'd be nice to have a standard, at least for the basic stuff.
I mean, HTML itself is well specified in the streets, and infinitely different flavors in the sheets. I don't _like_ that, the part of me that writes code _hates_ that. But the part of me that wants systems to succeed just had to sort of respect it.
*bold*
/italics/
_underline_
The problem is that that's too many characters to reserve (they all have to be escaped when you want the actual character) making the resulting text look awful in plain text mode.
+strikeout+
~code/monospace~
_subscript
* Heading
** Heading 2
** Heading 3
- bullet
- [1/2] checklist summary
- [ ] unchecked item
- [X] checked item
I see you, mlok, you fellow person of culture :)
But what you type isn’t even mrkdwn, but rather an input mode that supports most of the same syntax.
No format/vendor lock-in and very amenable to living in a git repo. For my note taking that's already game over right there against everything else. I don't want to worry about whatever cursed format OneNote uses is still something I can extract in 2035.
I also like that it's become a defacto standard that LLMs speak. I can tell it to look at the code in this server repo and make me a API_documentation.md and it'll grasp that I want a text based summary of how to use this endpoint
In fact, I like to write notes and documentation in text form, and then I notice I have been using Markdown all along, so I rename my text file into .md, fix a couple of markers, and now it looks nice on a viewer that supports markdown, and I have syntax highlighting in my text editor.
When I'm reading Markdown, I almost don't even see the symbols. Beginning a statement with a # immediately just looks like a heading, surrounding a word with asterisks looks italic to me, wrapping a string with backticks looks like code formatting to me, and my assumptions are generally right so I don't need to render very often (which is why the Pandoc -> LaTeX -> PDF pipeline didn't bother me that much).
If I'm writing LaTeX or something, I generally have a very rough idea of what something will look like, but it's not terribly reliable for me. I need to render frequently because my assumptions about how something is going to look is likely to be wrong.
I mostly use Typst now because it is similar enough to Markdown, and the compilation time is so categorically faster that I see little reason not to use it, but I still respect the hell out of Markdown for popularizing this kind of syntax.
Only just now has Windows Notepad been revised to render Markdown (I think it does now, anyway). And after searching for a Mac one I finally bought Marked. But that's all I could find. Otherwise you have to load MD files in some kind of editor and "preview" them. NO! I just want to double-click on the file and READ it, with the formatting applied. Why is that so hard?
Markdown is the intended rendering medium.
Try copying some markdown into these places:
- A reddit comment
- Microsoft Teams
- Slack
- Discord
- Google Docs
- Discord
- Notion
- Facebook Messenger (although only on desktop I think)
Etc.
Huh? Any open-source project on GitHub, at least, has the viewer right there. It's the default view of markdown files. I assume other repos are similar.
E.g. The readme https://github.com/jquery/jquery
It's officially only available for Linux (the Windows version is currently under development), and like I said, I don't use Apple products, and idk how familiar you are with manually compiling source code or how good Wine is on Macs, but maybe [Remarkable](https://remarkableapp.github.io/) could be an option?
Just thought I'd give my $2.70. ;)
The problem is that people want to use a web browser to display their documents, they want rich documents, and web browsers are awful at displaying text they don't understand the structure for. And <code> tags look consistently awful when read back, which is why we so strongly prefer syntax highlighting when we read XML or HTML.
Really, the big competition was BBCode, whose main problem is that it's too much like HTML, and Wikitext, whose main problem was that it's too bare-bones and domain-specific. The big advantages of Markdown are:
1. It's simply more readable. It pulls from how people were naturally formatting plain-text documents meant to be read as plain text rather than pulling from markup languages, so it more closely matches how people want to write documents in plain text. That makes the document easy to read while you're writing it. Asterisks for highlighting is an old convention, so were dashes and asterisks for bullets. Really, it made the asterisk an English punctuation mark for emphasis, which I think it genuinely is now.
2. It was easy to parse and short, which made it popular with Web 2.0 social media. It got picked up by Slashdot, Reddit, and Stack Overflow as "good enough" and "better than BBCode" for user generated content. Nobody liked using WYSIWYG editor boxes then, either. They were slow, buggy, and were often Flash-based before HTML5. They needed plain text formatting options, and BBCode was both annoyingly unnatural to type (just like HTML tags) and a little inflexible.
And nobody wanted to repeat MySpace and just let users use HTML. That was a horrible idea (Samy, XSS, etc.).
I think that is the biggest reason why Markdown doesn't support table. There are alternatives that do (e.g. wikitext) but they didn't get as popular as Markdown. Why? Perhaps it's because that tables will never really look fine in pure text no matter how clever your syntax is.
Isn't this a table?
|sn|name|
|--|--|
|1|George|
|2|John|
Edit: I get it now. It was not a part of the original spec.
|sn|name |
|--|------|
| 1|George|
| 2|John |
But perhaps it was the first big format that was followed a Unix-y "here's a CLI tool to go to HTML from this" thing, instead of some php script
Related reading: https://www.rfc-editor.org/rfc/rfc7763.html text/markdown registration.
> Straight double quotes (") and single quotes (') are parsed as curly quotes
I don't know who actually likes curly quotes, they are clearly excess to me. And as parsing sometimes fails (as the site says it may), you get inconsistent results, and failures stick out like a sore thumb.
Here is another syntax: this is <*bold>. Very unlikely to clash, can be vibe coded in an hour. But it's more of the same.
For reading, I don’t know who prefers straight quotes.
For writing—
There are more than a few people on HN who deliberately type curly quotes and other non-ASCII punctuation, due to a strong preference for them. I’m one of them.
I use Compose sequences: ; ; for left single quote, : : for left double, ' ' for right single, " " for right double.
(Accordingly, I hate being subjected to automatic curlification, partly because it’s not always correct, but more because if I typed ' or " you better believe I meant ' or ".)
It's just plain text, so no vendor lock-in and you can ripgrep/fzf/grep through it Lives happily in git repos with proper diffs LLMs speak it natively - they output Markdown, they understand Markdown input Way easier for agents to parse than PDFs (which are binary, layout-focused, tables turn to mush) Can do tables (at least in GFM), headers, code blocks, links - all structure preserved
What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?
A major limitation of Markdown is the lack of standardization. For example, even within GFM there's multiple subtle variants: a single new line becomes a space when rendering Markdown files, but a line break in issue comments.
I suppose, since Commonmark specifically has HTML block and raw HTML inlines, any chunk of HTML is by definition valid Markdown.
If you allow Markdown input you have to give a cheatsheet showing which "flavor" you are using.
This sucks for sharing documents with other people, but in practice it's not a problem. 99% of my writing never leaves my notes app or blog. And when it does, I often export it to PDF or Word to make it easy for non-techie people to read (I love Pandoc for this, it's easily one of the favorite tools in my daily toolkit).
https://blog.codinghorror.com/standard-markdown-is-now-commo...
So we are left in the mode where markdown remains needlessly fractured. Different flavors that render slightly different and everyone gets a little annoyed but they deal with it ands occasionally bemoan the fact that there’s no standardization.
Some "extended" flavors will allow you to embed HTML and CSS which solves the layout problem. It's not really markdown at that point, though.
> embedded binary content,
If you're using one of the extended variants, you can b64 encode images... but again, that's not really the spirit/intent of markdown.
> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
[0] https://daringfireball.net/projects/markdown/syntax#html
Multi-level lists, annoyingly, get rendered as code at the deeper levels because of the 4+ spaces from the beginning of the line.
This is a serious and major drawback of markdown, making it good for developers only. The average person does not want to render code.
Remove that one drawback, and it'll get even better adoption.
> I just went 22 levels deep with Zed and Marked
Sounds like you're agreeing with me :-/
Or are you arguing that the average person is a programmer, using programming editors and JS libraries?
Yes there is. The Common Mark spec, from 2014, says 4+ spaces indents are code. Nested lists go beyond 4+ indents pretty fast.
And that’s the main issue with Markdown.
Not so. You just need to be principled with your indentation, adding four spaces or one tab for every level of nesting.
1. Here is a thing.
- See, it works.
Nothing is amiss.
2. If you want to align everything…
- Then it looks like this.
Then it doesn’t seem so weird.
Off the top of my head: Math typesetting, semantic markup, small caps, document sectioning. (All of these things are very important for me.)
I appreciate that Gruber brought this very helpful thing into the world, but OTOH he was such a prick about the whole Standard Markdown debate, for no real reason other than ego. And it resulted in Markdown remaining an ill-defined standard to this day, with occasional compatibility issues still cropping up even though most platforms support most of "Github-flavored Markdown" (itself a stupid name and indicative how badly this has gone).
I don't agree that the Standard Markdown effort, had it succeeded as originally laid out, would've resulted in "hyper-corporate standardization". I mean, one of the main actors was Jeff Atwood, just about the least "hyper-corporate" guy there is. And I also don't really see any possible trajectory for Markdown to get "enshittified": after all, for the most part it's just plaintext with formatting conventions that existed way before it. Even if some corporate entity had somehow badly messed it up, markdown.pl and the other pre-existing implementations would have continued to exist.
My impression was he pretty much threw up a Perl implementation that was good enough for what he wanted, refused to refine it at all, and declared by the power vested in him by nobody in particular that if any parser implementation differed in behaviour to his (like, to fix bugs or make it better), wasn't true Markdown and wasn't allowed to be called Markdown.
Or perhaps I am being uncharitable in my interpretation of events.
It's not necessarily that writing HTML or other markup flavors is harder (obviously it is), but the beauty of Markdown for me is that it's perfectly readable in its raw form as well as with an applied styling.
And speaking of customizing the 'look' of markdown, a shameless plug for a markdown editor I've been working on with extensive customization options: https://kraa.io/about
Easier to understand Shape it creates is scannable
GitHub render it by default
Out of curiosity, do you mean the "autocomplete" feature or the import/export/copy/paste feature? (I did both)
And yup, the command palette search change was awesome. Can't take credit for that one though haha
I know that in my younger years I would get a lot of flak for converting .rst files into .md when I joined projects.
(As I got older I just stopped seeing .rst that much)
it's like YAML: it looks so simple at first, and then the horrors start if you try to use it seriously.
in both cases the most horrors lie in the spaces/tabs/newlines.
I agree entirely. But it's a lovely format to use. Programming as a profession is entirely about making things easier for our users, even if it means making things harder for ourselves.
After all, that's the whole ethos around the web as a platform. Throw some broken HTML soup at a browser and it'll still try its best to render it.
It's a TUI md reader, fast and cheap on the memory, because of Rust. Give it a try if you find yourself wanting a quick MD reader in a terminal.
Markdown did not come up with the idea of lightweight markup languages (LMLs). It just happened to become the most popular one, for reasons that the article doesn’t really address. There were other LMLs before and after Markdown. (It does mention Textile later on, but doesn’t mention that there were a number of others, and that it was a field that had been steadily developing.)
> What if you could just write out the text and then the link, sort of like you might within an email? Like: [Anil Dash’s blog](https://anildash.com)!
No one would ever have spelled it like that. It would rather have been either “Anil Dash’s blog (https://anildash.com)” or “Anil Dash’s blog <https://anildash.com>”.
> If mark_up_ is complicated, then the opposite of that complexity must be… markd_own_.
I’m guessing this was intended to have actual italics. (Clearly it wasn’t checked after writing, or else the third underscore would have been shifted before the d.) This shows one of the problems of Markdown. (“_anti_commercial” later has the same problem.) Also why you should prefer * for italics rather than _ when writing Markdown, because in CommonMark it allows you to mark up partial words. Throw away Prettier’s Markdown formatting, by the way, it’s terrible and if you’re not careful may destroy your content, and it insists on underscore for italics.
> Hitting the Mark
> [Stuff about Markdown becoming supported by Google Docs, Microsoft Notepad, Slack, WhatsApp, Discord, Apple Notes.]
A lot of this is wrong:
• What most of them have added is an input mode for their WYSIWYG editor which is best expressed as inspired by Markdown. If you want to actually deal in Markdown, they are always infuriatingly incomplete and incompatible. At best (and it’s never even that good) you’re only typing Markdown, not editing Markdown.
• What most of the rest of them have is a lightweight markup language only superficially similar to Markdown. Slack’s mrkdwn and WhatsApp’s formatting are this.
> The Ten Technical Reasons Markdown Won
I’ll grant 1 as valid but non-technical. 2 as valid for Markdown and less valid for other LMLs for reasons that I’ll get into shortly. 3 as valid for Markdown but also some other LMLs that already existed. 4 as valid and somewhat technical. 5 I won’t grant as distinct from 4. 6… well, the key there is actually that correctness isn’t as important as some of us would like. The flavours part of it was more a building up of technical debt. 7, 8, 9 and 10 I will not grant as reasons that Markdown won—several other LMLs already existed with the same benefits.
But it really misses out on the big reason, though 2 and 6 nudge on it:
Markdown won because it was simple, and extended HTML. It was horribly underspecified and all early implementations were all awfully buggy, inconsistent and incompatible, but it was simple and we didn’t care so much about those problems in those days (for better or for worse). People could implement Markdown themselves in an hour or two.
Nowadays, people familiar with Markdown will look baffled at some of reStructuredText’s syntaxes, but at the time I’d say Markdown and reStructuredText were similarly weird, just in different areas. When getting away from things like BBCode which was almost just HTML with square brackets, and Textile which had more idiosyncratic spellings (I mean things like “bq. ” where email had “> ” on every line), reStructuredText and Markdown were about equal.
reStructuredText is way more technically sound. It’s more capable than Markdown, and there’s none of the wild and incompatible fragmentation. But reStructuredText is heavy to implement, and if you only care about outputting HTML and only for yourself, it’s actually harder to extend—you’ll have to define a node type and extend the writer to know what to do with it, or else use the “raw” directive or role. Whereas with Markdown, you just wrote HTML and hoped for the best. Because Markdown was such a mess. But you’d get it right faster than in reStructuredText.
It’s no coincidence that there’s only one major implementation of each of reStructuredText and AsciiDoc, and only three or four total for each. They were designed for bigger, heavier things. Markdown was designed for simplicity at the cost of correctness… just like HTML was.
Perhaps md is an opportunity to re invent the web: a browser for just md AND a search engine with an open algorithm that indexes just what is visible.
pandoc readme.md | lynx -stdin
I like the results better than glow, bat and a few other viewers.
ChrisArchitect•14h ago
IYKYK. Joyent. TextDrive. Textpattern CMS.
Imagining an alternate universe where it might have been Textile. https://textile-lang.com/
Really it comes down to historically the time and place when Markdown was needed and the power of momentum leading to its mass adoption.
kstrauser•11h ago
anildash•11h ago
This piece was already pretty long, so I cut out most of the sidebar about Dean Allen and Textile, but he was a special guy, and certainly influential on so many parts of this era, not just Markdown.
SoleilAbsolu•10h ago
BeetleB•10h ago