search

remarkjs / react-remark

React component and hook to use remark to render markdown
https://remarkjs.github.io/react-remark
MIT License
208 stars 7 forks source link

Difference with react-markdown #3

Closed heri16 closed 4 years ago

heri16 commented 4 years ago

How does this compare with react-markdown and remark-react in terms of architecture and performance?

ChristianMurphy commented 4 years ago

@heri16 there is an overview at https://github.com/remarkjs/react-markdown/issues/427

I can expand on that in three ways: architecturally, API wise, and performance wise.

Architecturally, https://github.com/remarkjs/react-markdown/issues/427 is a good overview, react-remark replaces react-markdown's custom mdast to react parser with remark-rehype and rehype-react. this reduces code size are more logic is pulled from upstream, and increases API flexibility.

API wise, this adds new ways to customize the API rather than taking them away, Remark is used same as before and has the same options as before. customizing rendering now has two entry points, one for customizing how markdown should be translated to HTML, one for customizing how HTML should be translated into react components. Having this distinction allows plugins like: https://github.com/remarkjs/remark-math, https://github.com/zestedesavoir/zmarkdown/tree/HEAD/packages/remark-abbr, https://github.com/zestedesavoir/zmarkdown/tree/HEAD/packages/remark-custom-blocks, https://github.com/dimerapp/remark-macro, https://github.com/zestedesavoir/zmarkdown/tree/HEAD/packages/remark-sub-super, and https://github.com/landakram/remark-wiki-link (just to name a few) to work. Since they need to transform both the markdown and the resulting HTML. hyperscript is still used to handle transforming markdown to html and html to react (see: https://github.com/syntax-tree/mdast-util-to-hast#optionshandlers and https://github.com/rehypejs/rehype-react#optionscomponents) which keeps the familiar react createElement syntax and option to use JSX.

react-remark also comes with less defaults, providing a minimal path from markdown to react, and offering recipes for additional syntax through examples in storybook. open interpretation of https://github.com/remarkjs/react-markdown/issues/427 in discussion would be releasing react-remark without defaults as it's own package, and making react-markdown a preset group of plugins/syntax features that closely lines up with the existing feature set.

Performance wise, as in most cases with performance "it depends". It's hard to give a fair comparison because for many valid inputs react-markdown crashes on (see the issues referenced in https://github.com/remarkjs/react-markdown/pull/428) For valid markdown to react, they are about the same. For valid raw HTML to react, react-remark is slower due to https://github.com/rehypejs/rehype-raw but it produces correct output in places where react-markdown does not. For incomplete markdown to react and incomplete raw HTML to react, there is no direct comparison, react-remark will render the escaped or HTML interpretation (in the case of unclosed tags) of incomplete output, react-markdown will crash.

ChristianMurphy commented 4 years ago

Expanding some more on performance, looking at it from a different angle react-markdown vs react-remark from a user experience perspective. Both are best suited for a live editing perspective, producing output which can highlight where issues are happening (which react-markdown does) can allow authors to find issues faster than trying to interpret a stacktrace (react-markdown's current behavior).

For a high performance/SEO optimized display, transforming server side would have a major performance boost, either library may be usable with next.js, a different utility may be needed for Gatsby and Webpack support. (another related project in the unified ecosystem MDX took this approach)