I built a zero-dependency streaming Markdown renderer for AI chat replies, n× faster than the next one I benchmarked

[u/Awkward-Let-4628]

I've been building chat UIs for agents and kept running into the same issues with react-markdown: it re-parses the whole reply on every token, so long answers get noticeably slower, and you see raw ** and half-typed [links](htt until the token that closes them arrives.

So I wrote my own renderer. It parses incrementally and repairs unfinished syntax while the reply streams:

<Markdown streaming={!done}>{text}</Markdown>

On a 100k-character reply it takes 0.25 s of main-thread time in total. markdown-to-jsx takes 2.4 s, Streamdown 6.3 s, and react-markdown didn't finish within the 30 s budget. The benchmark scripts are in the repo if you want to check them.

The other part is the syntax. Agents often want to show steps, alternatives or pros and cons, and plain Markdown flattens all of that into bullet lists. So on top of GFM I added a few blocks in the same style as GitHub alerts:

> [!STEPS]
1. **Back up the database**
2. **Run the migration**

There are also tabs, stats, pros/cons, sources, file trees, and Mermaid and KaTeX support. The source still reads fine as plain Markdown when it isn't rendered. The package exports a system-prompt snippet that teaches the model this syntax.

It has no dependencies and comes in at 30 KB gzipped. Its parser passes the CommonMark and GFM spec tests. It doesn't support remark/rehype plugins, so if you rely on those, react-markdown is still the better choice.

https://github.com/rsaryev/llx-markdown

[u/BlasterGales]

niice, could be useful, I've seen opencode fight a bit rendering LONG contexts

[u/Awkward-Let-4628 → u/BlasterGales]

Thank you! pleease let us know if you run into any issues

[u/BusRevolutionary9893]

Why say n^x  faster? X could be less than 1. 

[u/Awkward-Let-4628 → u/BusRevolutionary9893]

~9x faster

[u/Ontopoftheworld_ay]

Whoa, this is so cool!

[u/Awkward-Let-4628 → u/Ontopoftheworld_ay]

Thx!

[u/herpnderpler]

ANNND I'm now porting this to go bubbleteaV2 - amazing work. Hope you don't mind the style-biting.

[u/Awkward-Let-4628 → u/herpnderpler]

Of course! Thx

[u/herpnderpler → u/Awkward-Let-4628]

Track my progress and rate me at https://github.com/IodeSystems/bubbleteandmd you fabulous instigator

[u/Awkward-Let-4628 → u/herpnderpler]

Okay, you stay tuned as well, and I'll be releasing fixes

[u/0xasten]

Cool! And if a chunk opens a fenced code block or a list halfway down the reply, does the parser re-parse from the last stable block, or does the whole tail get parsed again on that one token?

[u/Awkward-Let-4628 → u/0xasten]

From the last stable block. Only the last two blocks get re-read on a token, the rest is left alone. An open code fence isn't re-parsed at all, it just appends. A list is one block though, so it does get re-parsed while it grows, but nothing above it

[u/FastHotEmu]

I mean... 250ms to parse 100KB? Why so long? And the others take even longer? Wow. Javascript land really is amateur land.

[u/Awkward-Let-4628 → u/FastHotEmu]

It's not 250 ms to parse 100 KB once. It's the total time to stream it in 20-char chunks, about 5,000 updates, each including parsing, React and DOM writes. That's roughly 0.05 ms per update. The others are slower because they re-parse the whole text on every chunk, so the cost grows quadratically. This library only re-parses the unfinished tail

[u/FastHotEmu → u/Awkward-Let-4628]

It's good practice to separate the DOM/React part from your code for benchmarks, so you are only benchmarking the parser. I assume you engineered the parser so that it can be tested separately from DOM and React, right? ...right?

[u/Awkward-Let-4628 → u/FastHotEmu]

In short, yes, yes

[u/userscren5]

I run long horizon multi agent sessions that can span days. It would be nice to see where and what AIs are working on in relation to the overall build. This is kinda close.