markdown-it - markdown / CommonMark parser on steroids
Not so long ago, there was a lot of noise about CommonMark 's initiation to unify Markdown. It would seem that at last in this wonderful markup comes order. But in practice, not everything is so simple. Now work is underway on the basic syntax, and the extensions will not come soon. Not everyone can wait a year or more. But the development of specifications - it is rather a scientific work. We are also interested in practice - how to screw a markaun to specific projects.
What can a programmer need from a good Markdown parser? Well, of course, not the speed :). And you really need the ability to add your own syntax extensions. Unfortunately, in all implementations of parsers that I met before, the logic of parsing markup is pinned tight. All that remains is to pick the end with a nail and hope that there will be no conflicts. Of course, it is impossible to guarantee reliable exhaust. You can go the other way - try to send a patch to the upstream. But there are no guarantees that the syntax of your extension will be needed by someone else besides you, and that your code will be accepted.
How to be? Fortunately, we now have markdown-it !
')
How is markdown-it different from other parsers?
1. Ability to change the rules of parsing. You no longer depend on the opinion of the authors of the project - make your plugin and be happy.
2. Strictly following CommonMark.
3. Support for tables and crossed out text, as on github. In the near future, the authors plan to add other popular extensions.
4. Any bonus buns like a typographer, the rules of which can also be supplemented.
Demo
The funny thing is that with all the plump system plugin parser works very quickly. It is 2-3 times ahead of the reference parser written in javascript, and according to estimates, it should lose the variant in C only two times. Apparently affects the experience of developers. At one time I already wrote about their port zlib, showing impressive speed.
What else is useful in the parser from a practical point of view? Completely eliminates the need to use embedded HTML (after all, you can add everything you need through plugins). Accordingly, there is no need for validators to protect against XSS. This is very convenient, especially for browsers, where not to drag spreading server packages like OWASP.
In general, the result is very impressive, because building a configurable parser is not an easy task by itself, even if you don’t think about speed. Well, the practical benefits are obvious.
Project address on github - github.com/markdown-it/markdown-it
What can a programmer need from a good Markdown parser? Well, of course, not the speed :). And you really need the ability to add your own syntax extensions. Unfortunately, in all implementations of parsers that I met before, the logic of parsing markup is pinned tight. All that remains is to pick the end with a nail and hope that there will be no conflicts. Of course, it is impossible to guarantee reliable exhaust. You can go the other way - try to send a patch to the upstream. But there are no guarantees that the syntax of your extension will be needed by someone else besides you, and that your code will be accepted.
How to be? Fortunately, we now have markdown-it !
')
How is markdown-it different from other parsers?
1. Ability to change the rules of parsing. You no longer depend on the opinion of the authors of the project - make your plugin and be happy.
2. Strictly following CommonMark.
3. Support for tables and crossed out text, as on github. In the near future, the authors plan to add other popular extensions.
4. Any bonus buns like a typographer, the rules of which can also be supplemented.
Demo
The funny thing is that with all the plump system plugin parser works very quickly. It is 2-3 times ahead of the reference parser written in javascript, and according to estimates, it should lose the variant in C only two times. Apparently affects the experience of developers. At one time I already wrote about their port zlib, showing impressive speed.
What else is useful in the parser from a practical point of view? Completely eliminates the need to use embedded HTML (after all, you can add everything you need through plugins). Accordingly, there is no need for validators to protect against XSS. This is very convenient, especially for browsers, where not to drag spreading server packages like OWASP.
In general, the result is very impressive, because building a configurable parser is not an easy task by itself, even if you don’t think about speed. Well, the practical benefits are obvious.
Project address on github - github.com/markdown-it/markdown-it
Source: https://habr.com/ru/post/241766/
All Articles