Show HN: Fast and Extensible Parser for Markdown in PHP
1–10 of 39 posts
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#2I remember seeing this on /r/PHP, and one of the top comments there was about it using Regex instead of parsing it like a language.
However, I also recall that it's thanks to using regex that it works so quickly. So I figured I'd get this argument out of the way before someone else brought it up.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#3Parsedown is certainly very fast, but I wouldn't call it "extensible". CeBe's markdown parser is nearly as fast, but focusses on being very easy to extend, so it's trivial to add custom syntax elements, see https://github.com/cebe/markdown
(CeBe's library is inspired by parsedown)
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#4Looks great, happy to see the Markdown Extra extension. With regard to performance, I'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.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#5I remember seeing this on /r/PHP, and one of the top comments there was about it using Regex instead of parsing it like a language. However, I also recall that it's thanks to using regex that it works so quickly. So I figured I'd get this argument out of the way before someone else brought it up.
I think semantics parsing with lexer/tokens is better for a lot of things but it sometimes overkill when the patterns are predictable and simple.
That said, has there ever really been an issue with speed as it pertains to markdown translation? I can't imagine it's an everyday, practical concern.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#6I remember seeing this on /r/PHP, and one of the top comments there was about it using Regex instead of parsing it like a language. However, I also recall that it's thanks to using regex that it works so quickly. So I figured I'd get this argument out of the way before someone else brought it up.
I think semantics parsing with lexer/tokens is better for a lot of things but it sometimes overkill when the patterns are predictable and simple. That said, has there ever really been an issue with speed as it pertains to markdown translation? I can't imagine it's an everyday, practical concern.
As with most tech, if there such a leap in speed (about 10 times) then a lot of other applications become possible. You could remove a layer of caching because its not needed anymore, thus reducing your app complexity. But apart from that, imagine how many places use markdown? If people all move to a 10 times faster implementation, that an incredible reduction in wasted cpu cycles.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#7I remember seeing this on /r/PHP, and one of the top comments there was about it using Regex instead of parsing it like a language. However, I also recall that it's thanks to using regex that it works so quickly. So I figured I'd get this argument out of the way before someone else brought it up.
I think semantics parsing with lexer/tokens is better for a lot of things but it sometimes overkill when the patterns are predictable and simple. That said, has there ever really been an issue with speed as it pertains to markdown translation? I can't imagine it's an everyday, practical concern.
If you're building a static site from markdown files, and your site consists of thousands of pages, speed will definitely be a concern.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#8Earlier quoted context omitted.
I think semantics parsing with lexer/tokens is better for a lot of things but it sometimes overkill when the patterns are predictable and simple. That said, has there ever really been an issue with speed as it pertains to markdown translation? I can't imagine it's an everyday, practical concern.
As with most tech, if there such a leap in speed (about 10 times) then a lot of other applications become possible. You could remove a layer of caching because its not needed anymore, thus reducing your app complexity. But apart from that, imagine how many places use markdown? If people all move to a 10 times faster implementation, that an incredible reduction in wasted cpu cycles.
My point was not that we shouldn't work to produce even small efficiencies (which, yes, cascade into larger aggregate ones).
It was more wondering whether speed in markdown parsing is such a concern that this would merit a marquee 'selling' point.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#9Parsedown is certainly very fast, but I wouldn't call it "extensible". CeBe's markdown parser is nearly as fast, but focusses on being very easy to extend, so it's trivial to add custom syntax elements, see https://github.com/cebe/markdown (CeBe's library is inspired by parsedown)
> Parsedown is certainly very fast, but I wouldn't call it "extensible".
Parsedown is extensible and it already has been extended. There's a well working extension of Parsedown that adds support for Markdown Extra. It's called Parsedown Extra. It can be found at https://github.com/erusev/parsedown-extra
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#10I remember seeing this on /r/PHP, and one of the top comments there was about it using Regex instead of parsing it like a language. However, I also recall that it's thanks to using regex that it works so quickly. So I figured I'd get this argument out of the way before someone else brought it up.
I think semantics parsing with lexer/tokens is better for a lot of things but it sometimes overkill when the patterns are predictable and simple. That said, has there ever really been an issue with speed as it pertains to markdown translation? I can't imagine it's an everyday, practical concern.
> That said, has there ever really been an issue with speed as it pertains to markdown translation?
Yes, speed of translation is a big deal. I tried at least 4 Markdown parsers for Python precisely because I needed the right combination of speed and extensibility. When you are constructing a very large static site, a full rebuild can take a long time.
For those wondering, I went with Mistune (http://mistune.readthedocs.org/en/latest/). It is accelerated by Cython.