I’m sharing this because I suspect it will be of interest to many on this forum.
I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation.
1 Like
It seems he’s advising that people not use Markdown for purposes for which it’s not designed. In other related news, I advise that you not use a torque wrench to hammer in roofing nails. 
16 Likes
I think this person completely misses the point of markdown. He only considers its usage as a tool for authoring content for the web. But as Obsidian has shown, it’s use goes far beyond that original idea that Gruber had in 2004. For me, the best thing about Markdown is that I can parse it with my eyes. If every markdown editor disappeared from the market, I could still open my files in TextEdit and easily make sense of it. This makes my notes future proof and not tied to the whim or economic health of software companies whose tools come and go with time. It also allows me to experiment with different tools at the same time. For example, I often use iA Writer and Obsidian together on my markdown files. There is no translation or import or export, one day I open the file in Obsidian, the next in iA Writer.
There are many other advantages that this author ignores. But his proposed alternative is some complex json format that ignores all the points I’ve made above. No thanks.
17 Likes
This guy, Knut, starts out fine but goes off the deep end. Sure, the most recent approaches to content creation and presentation can be very complicated and Markdown hasn’t kept up. But, so what? Very few people are forced to use Markdown. Techies and devs have no problem with Markdown, even if “forced” to use it. It is just one of the simpler things they have to learn. If non-techies like writers, bloggers, and reporters are forced to use Markdown, it certainly is a lot easier, for example, than many of the publishing systems at the big newspapers were. Everyone else, even Mac Power Users, should just avoid Markdown if they don’t like it. Markdown is not the only game in town. 
6 Likes
Interesting article and some very valid points. I’m also at the point of wondering if markdown causes as many problems as it solves, and especially, asking what drives its use. Like a lot of things in tech, and especially in the power user parts of it, the “audience” for “product” is often assumed to be pretty similar to the people doing its development. So note-taking apps, for example, devote huge effort to code and maths blocks and much less to setting comfortable typography and layout to make it easier and more pleasant to read.
It’s not a surprise that this happens - automobiles reflect the interests of people who design and make them at least as much as they attempt to meet the needs of non-motorheads who drive them.
There’s a lot of mythology around markdown. For example, its portability is only really about text - ever tried seamlessly moving markdown with images to even another markdown app? It’s painful. But that said, there is a power in markdown. It’s a great syntax to use to write, there are now some really great editors that mean your writing isn’t code and it’s efficient and reliable for storage and transmission too. It works very well for such things as blog entries in CMS.
Really great developers understand the problems they are trying to solve for users. They don’t assume that their users or use-cases are just like their own and they are trying, for example, to make it easier and better to write and adopt the data structures and algorithms that will best meet that need, rather than starting by assuming it will be markdown.
3 Likes
For a second I thought it was Donald Knut.
10 Likes
One of the problems that markdown solves is especially apparent in mobile environments. Neither Apple nor Android have an RTF text editing API. So every developer that wants to provide rich text in his or her application has to write an RTF texting environment from scratch, and it never will work as well as a private API that is missing.
I’d love to use Nisus Writer, but it uses RTF as its default file format, which means it’s files ought to remain on my laptop’s file system. Try emailing an RTF document - many times the raw text formatting will be displayed on the receiving end.
6 Likes
It is obvious you have not become acquainted with the NotePlan app.
Your historical memory is accurate! This is exactly the pain point that Markdown solved for me!
2 Likes
Nice connection! A bit fractured, but nice.
3 Likes
For writing prose, I mostly agree. However, markdown makes it very easy to make notes that contain code.
import bla
print("bla.thing")
def etc():
do.that.thing()
I know that when I enclose code in the triple-quote blocks I won’t have to worry about copying it out later. Rich text often substitutes typographic characters for things like quote marks, which have specific meanings in code.
3 Likes
You don’t need an API for RTF.
It’s so basic to the OS that one of the first XCode tutorials has you creating an app that’s a reduced feature set of TextEdit.
RTF is built-in to TextView, for instance. Here’s the SwiftUI tutorial for buildinf a Rich Text editor for iOS.
Without even looking anything up, I’m going to say no. RTF had been intrinsic on the Mac for a long time. But back during Dropbox’s initial heyday, when blogging on one’s own site was popular, there was no RTF “built in” to iPhone OS as it was known at that time. Swift did not exist. Plain text editors were a dime a dozen and all the cool kids used Dropbox, plain text, and then Markdown to sync their writing between devices. It wasn’t even called Note Taking then.
Before OS X, back in the days of OS 9, we used Apple supplied code (in Pascal and later in C) to support importing and exporting RTF in HyperCard.
You’re still not talking about iPhones let alone iPads.
Did you actually look at this?
That’s from 2018. It’s for iOS.
It still works in the current version of Swift and Xcode.
Creating a text editor with RTF support is still, even now, the standard first Project tutorial for macOS, iOS, and iPadOS.
Text View is still part of the standard Object Library even on watchOS. It automagically includes RTF support, including the ability to “eat and spit” RTF.
Where it gets tricky is supporting Apple’s own RTFD.
There was what seemed like a long time between the iPhone introduction in 2007 and when the new Swift language began to be useful, when neither iPhone OS nor the renamed iOS had RTF capabilities built-in. That was the time period when plain text (and Dropbox and Markdown) became popular and really took off.
Apple’s Swift programming language: Cheat sheet | TechRepublic
When Apple announced Swift at WWDC 2014, the company reported that conference attendees were using one of the first publicly released Swift apps: the WWDC app. It was developed partially in Swift, and allowed attendees to view session schedules, maps and more.
1 Like
The iOS text widget has supported rtf forever. Since at least when you could build standalone apps. Heck the original iOS web view widget could probably do it even before the App Store existed.
I don’t like markdown for a different reason. It’s a terrible markup format for text. There’s a lot better options out there such as org and restructured text.
1 Like
RichText Edit for the iPad – At Last! – The Mac Observer
By Ted Landau
July 18, 2012
At last! The wait is over.
There has never been an iOS app that can create or edit .rtf (rich text format) documents. Until now. It’s called, appropriately enough, RichText Edit. [Update: The app has since been renamed Textilus.]
The absence of .rtf editing in iOS has long been a big deal for me because TextEdit is my primary text editor on my Mac. As TextEdit uses .rtf as its default format, this iOS limitation meant I had no way to sync TextEdit documents to an iPad and edit them.
1 Like
Wondering if people are possibly talking past one each other due to a lack of clarity on this point from that article:
There has never been an iOS app that can create or edit .rtf (rich text format) documents … The absence of .rtf editing in iOS has long been a big deal for me
When we’re talking about “support” for a given text format, that “support” runs along a continuum:
- “This software can read and display a given text format”
- “This software is capable of writing a given text format”
- “There’s a useful UI that allows you to create and format documents in a given text format”
Since we’re having this discussion on a forum, consider standards like BBCode. Years ago I saw forums that addressed points #1 and #2, but not #3. If you knew the magic code, you could format text - but the UI didn’t do it. The result was that there were certain people who could format their posts, and others who couldn’t.
I don’t remember right offhand, but I’m guessing that’s what at least part of the challenge was in early iOS - lack of a solid UI for editing RTF. If an app hits #1 and #2 but not #3, that’s not “support for RTF” in a way that’s useful to many people.
And that’s where Markdown really comes in. The editor doesn’t need to support it, and even if the viewer can’t “view” it natively it can show the Markdown - which is still very readable.
3 Likes