Earlier 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.
If you're building a static site from markdown files, and your site consists of thousands of pages, speed will definitely be a concern.
Show HN: Fast and Extensible Parser for Markdown in PHP
21–30 of 39 posts
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#22Markdown 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 "Markdown" or some variation.
I wish GitHub would drop the name "GitHub flavored Markdown", give it a clever new name, a cleverly branded website and use their bully pulpit to cast off Gruber's shackles and effect change.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#23It'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.
Easily solved by proper use of HTMLPurifier on the output.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#24I don't need another Markdown Parser. I need another Markdown. 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 "Markdown" or some variation. I wish GitHub would drop the name "GitHub flavored Markdow…
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#25I don't need another Markdown Parser. I need another Markdown. 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 "Markdown" or some variation. I wish GitHub would drop the name "GitHub flavored Markdow…
GitDown, GitDown
everybody GitDown now
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#26Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#27As debaserab2 says[1], if you are looking for speed, consider PHP extensions.
In my opinion, writing a system like this is a misappropriation of PHP, which evolved from and works best as a hybrid templating/scripting language. It becomes a powerful development platform when its extensive library of C functions is used to do most heavy lifting.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#28Earlier quoted context omitted.
Thus negating any speed improvements in the markdown parser....
Considering you have to run any markdown parser through a sanitizer, the speed improvements still matter.
edit:
To whoever downvoted me, I'm sorry, was I wrong? The markdown parser has to look at every input byte, obviously it's better to do the HTML sanitation at this level because the HTML parser must also look at every input byte, so, combine them into one pass...
Running HTMLPurifier on the output of the markdown parser is inefficient - it's sanitizing known good elements not just the potentially bad ones, so you're giving it more work to do.
Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#29Re: Show HN: Fast and Extensible Parser for Markdown in PHP
#30I don't need another Markdown Parser. I need another Markdown. 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 "Markdown" or some variation. I wish GitHub would drop the name "GitHub flavored Markdow…
I would like a complete template language based on Markdown.