3 ms·

Flattered to see it using marked for the markdown engine. Maybe the world is finally ridding itself of showdown.

• benaiah 13y ago
  What's wrong with showdown? Legitimate question - I just haven't heard of any complaints about it before.
  • chjj 13y ago
    I'll keep this as short as possible, but that's not easy. Speed: It's relatively slow (but fortunately faster than markdown.js at the very least). Quality: It carries with it a bunch of nonsensical quirks. Some of these quirks are inherited from the original markdown, some are unique to showdown. (I feel like I could write a treatise on list behavior alone, and how ridiculously showdown and markdown.pl handle them). It's not what people are accustomed to/find intuitive today. Here's a few problems (with showdown, as well as other engines) presented in a more tangible way: https://github.com/chjj/marked/blob/master/doc/broken.md https://github.com/chjj/marked/blob/master/doc/broken.md Code quality and maintenance: Showdown is a line-for-line port of Markdown.pl. As you can guess, this is not ideal, especially when you consider that the original markdown was written extremely awkwardly - it's essentially a pile of regexes doing global replaces on a single string to produce the output. This is _extremely_ confusing and messy to those who are not familiar with a code, and the original author of showdown, as far as I know, no longer maintains the project.
• rhythmvs 13y ago
  And rightly so! Marked indeed is a fine 𝗠⬇ parser! How would you compare your approach to e.g. markdown-js¹, mdown-parse-pegjs², or text.js³ (which are based on PEG parsing)? I would like to elaborate a bit on the specific differences/benefits between the many MD parsers. (I’m maintaining an inventory of Markdown resources in a repo on Github.⁴) [¹] https://github.com/evilstreak/markdown-js https://github.com/evilstreak/markdown-js [²] https://github.com/shamansir/mdown-parse-pegjs https://github.com/shamansir/mdown-parse-pegjs [³] https://github.com/sheremetyev/texts.js https://github.com/sheremetyev/texts.js [⁴] https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources
  • chjj 13y ago
    Thanks. Speed was originally marked's top priority. I would say marked's approach takes advantage of the fact that v8 generates _extremely_ fast machine code for regexes. This is just something I discovered through many endless nights of benchmarking the entire markdown test suite. Using complex regexes for the lexemes seems like a stupid idea to most people, but it allowed me to optimize marked like crazy, so much so that it beat discount(written in c) in benchmark times (It might be a little bit slower now due to the latest features. I decided to ignore speed for a while to focus on features - will get back to optimization eventually). The downside of all of this: marked loses some extensibility, however, we implement as much extensibility as possible by exposing the token stream and renderer. Accuracy and sanity quickly became marked's next top priority. There's a certain threshold of accuracy you want in a markdown engine (you don't want it to be too accurate because markdown.pl had a lot of bizarre behavior). That's a different story.
• bowerbird 13y ago
  chjj said: > Flattered to see it using marked for the markdown engine. i am amused as well. because i just did this the other day: > http://gitdown.wordpress.com http://gitdown.wordpress.com "gitdown" -- so we can all get down... * i also wrote a piece called "markdown considered harmful". > https://medium.com/the-future-of-publishing/495ccfe24a52 https://medium.com/the-future-of-publishing/495ccfe24a52 the world needs a new infrastructure for thoughtful documents, including a new text-editor. but from the look of it thus far, this github thing lacks _simplicity,_ by an order of magnitude. -bowerbird