The same mdast as remark-parse, much faster.

Streaming demo: a chat answer, token by token

One long answer is streamed into two panes, 40 characters per update. On the left, react-markdown re-parses and re-renders the whole message on every update, which is what most chat UIs do. On the right, samemark/stream parses only the new text and React skips every finished block (examples/react-chat).

Starting...

Both sparklines share one scale: 0 to 1 ms per update, left edge is the first update. Each number is the time of one synchronous React update (parse, render and DOM commit; layout and paint are not included), measured with performance.now() in your browser, on this device. Both panes run on the same thread, one after the other, in alternating order. No throttling is applied: open this page on a phone to see the difference on a slower device. The checked claim is the badge: the two panes must hold identical HTML, compared every 10 updates and at the end. Controlled measurements (Chromium, 4x and 6x CPU throttling, 7 rounds) are in the README.

Playground: the same tree?

Type markdown. Both parsers run in your browser on every change and the two trees are compared node by node, positions included. The sample is deliberately awkward: nested emphasis, a footnote, a table with escaped pipes, a reference definition used before it appears, raw HTML, autolink literals.

Parsing...

Try to break it: if you find an input where the two trees differ, open an issue and paste the input. That is exactly the bug report this project wants.

Parse time is per parse: one warm-up run, then the median of 5 batches of repeated parses in this tab (a single parse of a short text is below the timer resolution of browsers). A short input mostly measures call overhead; paste a large document to see the gap. samemark here is samemark/core with stock GFM (the browser build); the reference is mdast-util-from-markdown with micromark-extension-gfm and mdast-util-gfm.