Show HN: Fast and Extensible Parser for Markdown in PHP

I don&#x27;t need another Markdown Parser. I need another Markdown.<p>Markdown has outgrown its original spec, yet Gruber both clings on to it and is unwilling to update it. Meanwhile, different websites and different parsers proliferate, each adding new extensions with varying degrees of usefulness and compatibility, all under the name &quot;Markdown&quot; or some variation.<p>I wish GitHub would drop the name &quot;GitHub flavored Markdown&quot;, give it a clever new name, a cleverly branded website and use their bully pulpit to cast off Gruber&#x27;s shackles and effect change.

It&#x27;s important to remember that most markdown implementations (including his one) cannot be used to provide a safe mechanism for authoring user generated content without opening a site up to XSS vulnerabilities, since markdown allows arbritrary HTML markup.

Different markdown editors seem to be in disagreement how to parse the following: <a href="https://gist.github.com/anonymous/810ae1f7d52bcfffa1ef" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;810ae1f7d52bcfffa1ef</a><p>If the second empty line marks the end of the list block, the indented html (code block) should preserve tags

I remember seeing this on &#x2F;r&#x2F;PHP, and one of the top comments there was about it using Regex instead of parsing it like a language.<p>However, I also recall that it&#x27;s thanks to using regex that it works so quickly. So I figured I&#x27;d get this argument out of the way before someone else brought it up.

We started with a server side Markdown parser, but switch to a JavaScript parser (<a href="https://github.com/chjj/marked" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chjj&#x2F;marked</a>). Really there is no reason to do this work on the server.

I&#x27;ve worked with several markdown implementations and parsedown is my current choice due to my main constraint - speed. Great work and thanks for sharing.

Looks great, happy to see the Markdown Extra extension. With regard to performance, I&#x27;ve always gotten around the slowness of the original Markdown parser by making liberal use of caching, but warming the cache is still painful for a CMS. Will look to migrate to this.

Parsedown is certainly very fast, but I wouldn&#x27;t call it &quot;extensible&quot;. CeBe&#x27;s markdown parser is nearly as fast, but focusses on being very easy to extend, so it&#x27;s trivial to add custom syntax elements, see <a href="https://github.com/cebe/markdown" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cebe&#x2F;markdown</a><p>(CeBe&#x27;s library is inspired by parsedown)

Perhaps I am looking at this wrong, but I don&#x27;t see why you would use a Markdown parser written in PHP if you&#x27;re looking for speed. Case in point the parsedown system is fast because it has heavy use of regular expressions, which parse faster and run faster than the host language-- it already relies on a language other than PHP to essentially emulate parts of a well-written lexer.<p>As debaserab2 says[1], if you are looking for speed, consider PHP extensions.<p>In my opinion, writing a system like this is a misappropriation of PHP, which evolved from and works best as a hybrid templating&#x2F;scripting language. It becomes a powerful development platform when its extensive library of C functions is used to do most heavy lifting.<p>[1] <a href="https://news.ycombinator.com/item?id=7784219" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7784219</a>