3 ms·

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

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.

3 ms·

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

by rhythmvs 13y ago

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.