Hacker News Reader

The author is also a Sanity employee and, while I like the ideas behind the Sanity CMS, if you ever create a schema with an RTF field, you'll see the opposite extreme when you read the text back via GraphQL. If Markdown was created to make the source readable, Sanity exists to make content unreadable (via expansive nested JSON for even simple tags like <b>). It's pretty easy for a paragraph of text to take 200 lines of Sanity JSON.

Like Sanity, this author has expanded three paragraphs of content into 600 lines of text. I'm an avid reader but that doesn't mean I want to reread the same reworded premise over and over.

> Like Sanity, this author has expanded three paragraphs of content into 600 lines of text.

*snort* this is mischievous but funny.

I share with the author of the article the need for a standard format for presentation-independent structured multimedia content, and that html+js+css is now too complex for this purpose.

But I think that such a format should keep rich text separate from structure, in the same way that CSS keeps style separate from content. Content structure in a web environment is inherently complex, so there should be a standardized way to link markdown-style simple "pages" that have linear or shallow tree structures, to build the superstructure of a complete web site.

In my opinion that lack of a specific format for structure is what is limiting the growth of common tools for rich content. Wikis are the only example I know of an attempt to create such a format, but it works by having basically no structure, just uniquely named pages and hyperlinks between them.

I was astonished at the length of that article as I kept reading and thinking the same, ‘isn’t this what he just said before???’ I’m happy to read long-form but I feel that piece would have benefited greatly from substantial editing

Sorry about that. You won't believe how long the first verison was ;)

It could also use some editing and running through spell check, like that comment.

Exactly, Markdown is a great example of the "pave the desire path" philosophy.

https://en.wikipedia.org/wiki/Desire_path

> It didn't start when it was named and mapped to HTML. It was in use on usenet and in emails before HTML even existed. And most of its conventions came from typewriters before that.

It used established syntax, but it didn't start there. There are also other markup-languages, which use other established syntax from the old times. A language is not just some random parts.

> You could print out a Markdown document today and jump in a time machine to 1970 and hand it to someone and they'd understand it.

Because it's human-friendly by design, not because it's syntax already existed back then. There are limits to what people would understand in 1970 from the syntax.

> There are also other markup-languages, which use other established syntax from the old times.

Would you care to share some examples? I'm genuinely interested, while nothing obvious that would fit this description comes to my mind.

AsciiDoc, reStructuredText, textile, org-mode, they all have to some degree such syntax. Or just read old usenet-archives, FAQs and such. It's natural to do it if your aim is to be lightweight and readable. You just happen to use the elements you have at hand. And people did that, wrote all kind of texts and documents in ascii with made-up syntax on the spot, for usenet, e-mail, ftp-servers, etc. It's hard to say that something started here or there, if the path to it is so short.

More generally, markdown is but one (if the most successful) of the “lightweight markup languages” (https://en.m.wikipedia.org/wiki/Lightweight_markup_language).

Most of them have fallen into disuse following the ascendency of markdown, but anyone who was on the internet in the mid-aughts will remember textile and creole, they were major contenders in the CMS and wiki space respectively (IIRC).

Ah, I thought we're talking typewriter-old times. Yes, sure, I do remember the proliferation of weird wiki syntaxes, and I also remember seeing markdown as a breath of fresh air in its readability and intuitiveness. I do believe the same as the poster before me, that markdown is the closest among them to what could be seen either in typewriting, or on usenet. Asciidoc and rst have some of it, but break the illusion by introducing too much weirdness (see esp. the syntax for links and lists in both of them). Until proven otherwise, I can't believe those happening on usenet and not being ridiculed.

I would argue that rst is much closer to how things were done with typewriters. One example: I can not think of one document written on a typewriter that indicated a heading with #, but just a brief search for typewriter document images will get you ones with "--" underlines as headings. For me that is actually still the biggest difference between rst and Markdown, and I still think underlines look much more like headings, but I also find # much easier to write

Remember that Markdown supports both SETEXT (# header, ## header, ### header) and ATX (header\n======, header\n------) headers. I prefer SETEXT headers for writing since you can use all the supported hX levels, but if all you need is h1 and h2, then ATX headers are usable.

DocBook…

Readable is not a proposition, its a spectrum.

The beauty of JSON is that you can convert it to a more readable state. For example, an unjustify would force the correct enters, already improving readability (I still find it unreadable, but OK). Converting it to YAML would, in my opinion, increase the readability even further, but YMMV.

With the binary word processors, we had a vendor lock-in. Never again! If we got open standards, we can convert to/from another document format, including the Markdown language of your choice.

Readable to me is that you don't need to convert it to another format to be able to read or make edits. A textbox input on a webpage is sufficient for me to read and and write markdown.

And when you read my comment, you don't even have to know that it's markdown to be able to read it.

The moment you add a structure to it, you need to worry about having compatible parsers or it's going to forget to pull out some of your paragraphs and the like, and if there's a missing curly brace, your parser will throw an error. You'll still be looking at the obfuscated source data

Html is already the open standard, but people like markdown instead

Well, I have a somewhat fresh take on it, as complex algebra (and therefore mathematics and programming) yields me migraine-like symptoms. Sadly, if I might add. So I am def. in game for the most simple markup language (JSON isn't it, I know that much, its was convenient to pick up hype because people who work with web design already knew JavaScript which was and is popular among web designers or frontend devs as its called nowadays).

In the end, its all structured. Even a letter is structured, but just with language and courtesy rules (grammar, for example). There's different levels of quality and complexity in that field, too. There's only so much you can do with ASCII characters to make text more structured. You quickly descent into the world of adding programming syntax to it (one asterisk for bullet point or two asterisks for bold are already). You can keep it very simple, you still gotta know the markup rules, as simple as they are.

In gaming, there's an adagio: easy to learn, hard to master. I believe a good language holds true to that. Mathematics certainly does (with exceptions).

With regards to JSON though, when you unjustify it, and you use syntax highlighting, is it really that bad? I find the only annoying thing is when you add an entry, you have to ensure the comma is correctly there (or not), but syntax highlighting and habit helps there.

The author here.

Yeah, I'm well aware that markdown didn't happen in a vacuum and was inspired by plain text formatting conventions. But there is only that much you can cover in an already too long blog post. It wouldn't have changed my argument much either. It wouldn't be historically accurate to say that Markdown existed before Gruber/Swartz, like it wouldn't be accurate to say that HTML existed before Tim-Berners Lee, even though SGML and such was a thing.

I'm not arguing for a more proprietary binary word processor format either. Or that we should type JSON. It's actually possible to have decent WYSIWYG editors that does their job. And they won't get better if don't put our minds to them.

The point you're missing in this reply is the legitime user-unfriendly experience of markdown and the challenges it poses for developers who are trying to solve things for their teams and customers today.

I'll admit that a lot of users don't like it. And maybe someday there will be a WYSIWYG editor that lives up to the name. But after about 30 years of dealing with ones that don't, I might be a little jaded. Plain text conventions like Markdown may not be fancy, but they do at least work.

Huh? Markdown was created in 2004: https://en.m.wikipedia.org/wiki/Markdown

The tools you invoke, which predate Markdown considerably, and mentioning 1970s don’t make sense in that light.

I think the point may have been more that conventions like asterisks or dashes for bulleted lists, angle brackets for quoting, etc. were already heavily used conventions predating markdown, the specification.

You write:

> Huh? Markdown was created in 2004 …

Did you read OP?

> > It didn't start when it was named and mapped to HTML.

Markdown is a formalisation of conventions which were in common in email & news long before HTML even existed.

Yes, but the point of Markdown is mapping those conventions to HTML. The mapping was the new thing that made it Markdown.

Anecdotal, but I was using many of the same formatting conventions on early IM and message board platforms in the late 90s/early 00s, even when they didn't actually do any formatting in the program. That's long before the introduction of Markdown. Markdown was an attempt to take all of those community-accepted formatting conventions and standardize it into a single format. If I still had access to any of my messages from those plaintext messaging days and fed them through a Markdown renderer, they would look remarkably similar to what I had meant to say at the time.

Anecdotal to the second degree: my mom saw me typing in the format at the time and remarked that she had learned to use similar formatting when she learned the typewriter in the 70s (coincidentally, she taught me to type on that very same typewriter).

Is it identical to what it was in the 70s? I don't know for sure, but I doubt it. Is it similar enough that someone versed in Markdown can read the 70s typewriter formats and vice versa? Most likely.

Those ways of styling were firmly enough established that a lot of people thought Markdown was violating them by having asterisks render as italic instead of bold. Italic was represented with slashes!

Emacs' Org mode gets this right.

> We've had a variety of markup formats including HTML, XML, etc. which are relatively a pain to read or write.

Right, but Markdown relies on HTML (or whatever other markup it is pre-procesing) for anything difficult.

I like Markdown[0] but surely our job as technologists is to find better solutions than a system that requires you to escape asterisks in certain situations, or rely on a preview pane to work out what it will do.

[0] but YAML front matter should burn in the fire

I would argue that it may be a case of "less is more". Yes Markdown is limited, but the limits make the language trivial to learn, modify and understand. It also means that the format can be trivially displayed almost anywhere and converted to all sorts of other formats.

There will always be a tradeoff between simplicity and the feature set, I find that for the vast majority of my use cases Markdown is simply good enough.

When I read markdown docs on github I usually get a pleasant sense of familiarity, everybody tends to gravitate towards the same basic layout because that's what Markdown does. That's a feature IMO, it means that you can focus on the content, not waste time parsing the quirky layout.

Monthly reminder that Gopher should've won btw.

Check out Gemini, its format is even more limited than Markdown, and it's TLS-native unlike Gopher.

Gopher might have won if students had ~/public_gopher directories, but it was not to be...

Gopher would not and could not have won, for two very good reasons:

(Would not) -- it was more complex to implement, being stateful (and it lacked the markup flexibility of HTML, which was kind of a big draw)

(Could not) -- the University of Minnesota announced their intention to collect licensing fees on their Gopher server (and client, I think), which was invented there.

This was a key moment in the web's development, because as a response CERN disclaimed ownership of web technologies -- under some pressure from IBM, as I recall, and IBM threw their research weight behind HTML/HTTP[0]

And that was that, basically. All happened in a few weeks in 1993.

(I can't find you a link to a discussion of IBM's action, but I can describe in detail the flashback to a freezing-cold, excesively-air-conditioned Sun SLC workstation lab at the University of Reading where I first read about it)

People crushing on Gopher these days do make me smile. Sure, it's like vinyl records.

[0] though this is hazy, I think they also made a promise not to assert relevant patents they held

Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;)

Netscape Navigator handling images was also a Big Deal(tm). Of course, there could have been a graphical (X) gopher client that showed images, but just like the people who like gopher and gemini now dislike images, I suspect it was the same then (think of the bandwidth!)

It's hard to convey how intensely cool it felt to be part of the early web, and images, differently sized and colored fonts were a big part of it.

> Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;)

It's not so much at the creation -- it's several years in (four years in for HTML/HTTP). Though it is about when I became aware of it.

What I recall of the time is that the web was just becoming a point of research interest, and big firms had product R+D interest.

Like I say, I can't find anything to prove my recollection now -- so it could well be wholly unreliable! -- but my specific recollection from damn year 29 years ago is that IBM's response (and likely the response of others) to the Gopher server licence situation was to seek clarification from CERN over their intentions with the web. IBM also had patents (concerning hypermedia) that were relevant but were never asserted.

It would always have been Tim Berners-Lee's intention to not assert patents but CERN obviously was his employer.

> It's hard to convey how intensely cool it felt

Were you in that same workstation lab in Reading, then? Seriously, you had to wear a coat and scarf if you were in one corner...

No, it was a lab in Stockolm filled with Sparcstations…

cool = hip

Why would we think there is a better solution? There's only so many symbols on the keyboard. There's only so many symbols in ASCII. That's how you end up having to escape things.

An asterisk literal usually belongs inside single or triple backticks IMO, and you won't have to escape it there.

Right, but then you have to explain to end-users why they need to escape an asterisk, or why they have to have their content on screen twice -- once in source and once in frustratingly flickering preview.

Personally I think it is our job as web developers not to encourage this for end users.

(Unless those end users are writing a book, in which case, definitely. Markdown as a source for Pandoc is fabulously better than a wordprocessor)

Users can avoid having to escape the asterisk by using Microsoft Word.

It seems to me that you expect some perfect solution to exist, and it is this solution that technologists should make it their mission to find.

I think there is no perfect solution and we should navigate the trade-offs holistically, rather than focusing on a single imperfection like suboptimal asterisks.

> It seems to me that you expect some perfect solution to exist

First, I don't mean in the Microsoft Word scenario, really (where I think that for very many applications, especially most books and most documentation, it's a very good tool).

I mean on the web. If you're putting markdown in front of end users on the web, or even content contributors on the web, you're failing.

Second, you're putting words into my mouth when you talk about a perfect solution because I said no such thing. I clearly said better solution. The absence of a perfect solution does not make Markdown equally as good as other possibilities.

(For example, I believe that if you had to deploy a text-only editor to web-based end-users, Asciidoc is a more appropriate solution, even if I also accept it has lost the war)

I write academic articles and like to use markdown for that, but you soon run into limitations that require non-standard tools. Precisely formatted tables… citations… line numbering… page numbering… inline maths… image placement… none are part of basic markdown. Outputting nice text is a big complex job, as the existence of TeX (ugh) shows.

True, different tools for different jobs.

That brings back repressed memories of the painful experience when a client came in with a Quark file (desktop publishing) that they wanted converted into a website. Getting the data out was difficult enough, actually formatting it and trying to replicate the layouts and styles and all was a nightmare. (This was back in the IE 5/6 days, btw - none of the modern CSS niceties.)

Just because you can do something (in desktop publishing software or otherwise) doesn't mean you should, and certainly doesn't mean a document optimized for print is good for the web.

what's worse: (a) a preview pane, or (b) a bloated editor (msWord) or mysterious web format (google docs)

also, there's many WYSIWYG editors that do an awesome job (Typora, Zettlr, etc)

I really like Typora as it goes, I've used it myself, and I've begun to recommend it to people who are writing long-form documentation or books (because I like pandoc a lot).

I have not used Zettlr but I will look at it; thanks for the recommendation.

But I still think Markdown has little place in content management systems for end-users; it's obtuse.

fair point; outside of it's main use case (writing documents), we're better offer using more sophisticated tools