Live data from Hacker News

Show HN: Fast and Extensible Parser for Markdown in PHP

parsedown.org

21–30 of 39 posts

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#21
post #5

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.

Not all that often, unless either a) you're in the habit of frequently making broad changes, or b) your build tool doesn't take account of modification times.

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#22
I 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 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

#23
post #12

It'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.

Thus negating any speed improvements in the markdown parser....

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#24

I 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.

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#25

I 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 wish GitHub would drop the name "GitHub flavored Markdown", give it a clever new name

GitDown, GitDown

everybody GitDown now

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#26
post #23

Earlier quoted context omitted.

Easily solved by proper use of HTMLPurifier on the output.

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.

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#27
Perhaps I am looking at this wrong, but I don't see why you would use a Markdown parser written in PHP if you'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.

As 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.

[1] https://news.ycombinator.com/item?id=7784219

Re: Show HN: Fast and Extensible Parser for Markdown in PHP

#28
post #26
post #23

Earlier 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.

The markdown parser should be able to do it in an ideal world. Htmlpurifier is very slow.

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

#30
post #24

I 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.

AsciiDoc is similar to markdown and offers a much more extensive syntax, but it's no where near as common in the wild.

http://www.methods.co.nz/asciidoc/

Post reply on HN