Ask YC: Textile vs Markdown
22 comments
Don't forget the costs of using a "lightweight" markup:
You have to learn some new system of quoting and escaping. I don't know textile or markdown, but I just went over to http://textism.com/tools/textile/index.php and tried to put a </code> close tag inside the sample code. It's got problems.
You get approximately one chance at a correct conversion to a richer format: converting to html. Nearly any other conversion, such as from the wrong lightweight markup to another lightweight markup, is lossy.
These markups aren't very extensible. They can't store metadata (e.g. microformats), or if they do, it tends to be by allowing html tags mixed into the markup, which means we're back into quoting/escaping issues.
There tend not to be any WYSIWYG editors, neither for you if you one day want one, nor for a less technical user who you'll someday want to edit your document.
So given almost zero knowledge about your problem, I'd recommend a WYSIWYG html editor. Whichever one you choose, it'll occasionally screw up and corrupt your formatting. Or maybe there will be subtle differences between the preview layout and a final browser layout. If you think those kind of issues will be a problem, then you REALLY don't want a lightweight markup language.
You have to learn some new system of quoting and escaping. I don't know textile or markdown, but I just went over to http://textism.com/tools/textile/index.php and tried to put a </code> close tag inside the sample code. It's got problems.
You get approximately one chance at a correct conversion to a richer format: converting to html. Nearly any other conversion, such as from the wrong lightweight markup to another lightweight markup, is lossy.
These markups aren't very extensible. They can't store metadata (e.g. microformats), or if they do, it tends to be by allowing html tags mixed into the markup, which means we're back into quoting/escaping issues.
There tend not to be any WYSIWYG editors, neither for you if you one day want one, nor for a less technical user who you'll someday want to edit your document.
So given almost zero knowledge about your problem, I'd recommend a WYSIWYG html editor. Whichever one you choose, it'll occasionally screw up and corrupt your formatting. Or maybe there will be subtle differences between the preview layout and a final browser layout. If you think those kind of issues will be a problem, then you REALLY don't want a lightweight markup language.
You're a bit off on the WYSIWIG thing. Rich text editors don't generate Markdown, but they can be configured to generate extremely regular, limited HTML, which can be converted to Markdown easily (a la HumaneText). Computers are good at stuff like that.
Typical end users dislike raw HTML. Most of them don't know what a <code> tag is. Markdown (though probably not Textile) is superior to HTML for end-users in that you don't even need to know how it works to get better-than-raw-text results.
My company's product does Markdown, and my philosophy is this: tens of thousands of people edit Wikipedia. Most of them are not particularly computer savvy. Wikipedia has perhaps the most baroque and ineffecient markup syntax possible, and people still tolerate it. So, there's the lower bar. By all means, exceed it, but don't obsess.
Typical end users dislike raw HTML. Most of them don't know what a <code> tag is. Markdown (though probably not Textile) is superior to HTML for end-users in that you don't even need to know how it works to get better-than-raw-text results.
My company's product does Markdown, and my philosophy is this: tens of thousands of people edit Wikipedia. Most of them are not particularly computer savvy. Wikipedia has perhaps the most baroque and ineffecient markup syntax possible, and people still tolerate it. So, there's the lower bar. By all means, exceed it, but don't obsess.
Right, it’s interesting that you wind up seeing these formats extended with additional complexity, basically reimplementing HTML in their custom syntax, for dealing with the publishing/processing pipeline.
I suggest an editor like vim or Emacs with HTML modes that give you auto-indenting and tag completion key bindings. It’s really not that much more work to author straight HTML, and if it’s what you’re targeting anyway, you’ll be happier in the long run when you have to maintain it.
I suggest an editor like vim or Emacs with HTML modes that give you auto-indenting and tag completion key bindings. It’s really not that much more work to author straight HTML, and if it’s what you’re targeting anyway, you’ll be happier in the long run when you have to maintain it.
No matter what your editor does, editing in HTML is simply slower than writing a Markdown document. You may be overstating the complexity of things like Markdown and Textile.
I prefer Textile because I find the linking syntax to be much more intuitive (I can never remember what's in parens and what's in brackets in Markdown).
You just need to learn how the syntax works for reference-style links. Something like:
[Hacker News][hn] is a website.
[hn]: http://news.ycombinator.com/
You should generally use these all the time when writing documents you intend to maintain. For quick one-offs like blog comments, you can instead use:
[Hacker News](http://news.ycombinator.com/) is a website.
Once you actually use markdown for non-trivial documents, it is very easy to remember its syntax.
[Hacker News][hn] is a website.
[hn]: http://news.ycombinator.com/
You should generally use these all the time when writing documents you intend to maintain. For quick one-offs like blog comments, you can instead use:
[Hacker News](http://news.ycombinator.com/) is a website.
Once you actually use markdown for non-trivial documents, it is very easy to remember its syntax.
That's interesting, because I've heard that link syntax is one main reason people prefer Markdown to Textile. One issue with Textile-style links is that something like
"Foo Bar":http://foo.com/bar.
<a href="http://foo.com/bar">Foo Bar</a>.
<a href="http://foo.com/bar.">Foo Bar</a>
So it allows quoted strings on one side of the colon but not the other? Sounds like a bug to me!
This is my biggest problem with Markdown - I still use it because I'm too lazy to switch, but every single time I have to insert an image I have to check the syntax page to see if the title goes in parens or if the link does (while neither makes sense because regular links use brackets for both).
So while I use Markdown, I recommend Textile just so you can avoid this issue.
So while I use Markdown, I recommend Textile just so you can avoid this issue.
[deleted]
Since they are so similar, I think it helps to answer a few simple questions:
1. Do you need something that one has that the other doesn't?
2. Who's your target audience? Are they going to be writing a lot of markup? If so, considering the syntax differences is more important than say for blog comments where the only likely uses are bold, italic, and link.
3. How is the library support in your chosen language; are there any quirks? I remember at one point a bug surfaced in py-textile that had something to do with unicode chars so if you were using a lot of unicode chars it was better to go with Markdown.
If I had to pick one I generally like more it would probably be textile, but it's so dependent on the situation that I have no generalized evidence to support one being superior as a rule. If you only want to deal with one, period, I would probably go with Markdown just because, as mentioned, it is more widely used and therefor (slightly) more well-known (also highly dependent on audience) and likely to be better supported lib-wise.
1. Do you need something that one has that the other doesn't?
2. Who's your target audience? Are they going to be writing a lot of markup? If so, considering the syntax differences is more important than say for blog comments where the only likely uses are bold, italic, and link.
3. How is the library support in your chosen language; are there any quirks? I remember at one point a bug surfaced in py-textile that had something to do with unicode chars so if you were using a lot of unicode chars it was better to go with Markdown.
If I had to pick one I generally like more it would probably be textile, but it's so dependent on the situation that I have no generalized evidence to support one being superior as a rule. If you only want to deal with one, period, I would probably go with Markdown just because, as mentioned, it is more widely used and therefor (slightly) more well-known (also highly dependent on audience) and likely to be better supported lib-wise.
For general use, neither, but for personal use, Markdown. Unlike Textile, with its specific syntax, Markdown adapts to various implementations of email syntax (numbered lists actually use numbers, bulleted lists use hyphens or asterisks). Write it like it would look in an email, and it should format nicely.
Use Markdown. It works extremely well with TextMate, because all of TextMate’s heaviest users and bundle contributors use Markdown. Once you start using it, you certainly won't want to write any non-trivial text document in HTML ever again.
Different design goals.
Textile is more expressive. It has more features and does more stuff.
Markdown is more transparent. It's designed to capture the features of a text email message and render them in HTML.
Textile is more expressive. It has more features and does more stuff.
Markdown is more transparent. It's designed to capture the features of a text email message and render them in HTML.
Both of them will make you long for the days when you could have just typed in some simple HTML tags.
Umm, you can type regular HTML tags in a Markdown document. It parses just fine.
I think Markdown is more widely used, but I personally like Textile because it supports one thing that Markdown does not: footnotes. Otherwise, they are basically equivalent to me.
Most up-to-date Markdown implementations support footnotes (specifically the Python one does for certain, but the syntax has been around for a while).
The syntax is pretty easy. [^1]
[^1]: And really adds some jazz to blog entries.
The syntax is pretty easy. [^1]
[^1]: And really adds some jazz to blog entries.
I've put together a little survey to see what people prefer for markup. Check it out: http://luciddesign.co.nz/2009/2/9/textile-vs-markdown-vs-tin...
I'm a fan of the default syntax offered by [RedCloth](http://whytheluckystiff.net/ruby/redcloth/). It's Textile, but with bits of Markdown thrown in, such as link syntax. It's only available for Ruby, though.
I think it's fairer to compare Markdown + Smartypants to Textile.
That said, I still prefer Textile, I just like the syntax better.
That said, I still prefer Textile, I just like the syntax better.
If you use RTL languages like Farsi, Hebrew, ... both of them are kinda useless.
I've been considering the pros and cons of the 2 most popular lightweight markup languages, but can't seem to pull the trigger one way or the other.
I realize that ultimately it comes down to personal taste, like vim vs emacs, but I'd still like some external input. What do you prefer and why?