High‑Performance Streaming Markdown Renderer for Multi‑Platform Mini‑Programs (x‑markdown‑mini)

With large language models making streaming output the norm for conversational AI, rendering Markdown incrementally on mini‑programs faces three core bottlenecks: an unnecessary HTML intermediate layer, O(N²) repeated parsing plus full‑tree setData transmission, and rigid extension mechanisms that force costly forks.

Identified Limitations of Existing Solutions

Typical pipelines such as marked / markdown‑it → HTML → rich‑text, towxml / mp‑html, and wemark suffer from limited interactivity, performance loss on incremental updates, and lack of maintenance or adaptability for new mini‑program platforms.

Three Bottlenecks

Conversion bottleneck – HTML as a redundant middle representation.

Streaming performance bottleneck – O(N²) repeated parsing and full‑tree setData transfers.

Usability bottleneck – extensions are hard‑coded or globally scoped, making low‑cost business integration difficult.

Strategy 1: Remove the HTML Intermediate Layer

Instead of Markdown → HTML → node tree → render, x‑markdown‑mini parses the Markdown directly to a token array with marked.Lexer and maps tokens to MiniNode objects via renderTokensToMiniNodes. The resulting nodes map one‑to‑one to native mini‑program components ( <text>, <view>, <image>), enabling clickable links, image preview, and animations without the overhead of an HTML step.

Strategy 2: Stable‑Block Caching + Incremental Patch Transmission

Observing that already‑generated content is semantically stable, the renderer splits the output into a cached "stable block" (previous paragraphs) and an "active block" (the current chunk). The stable block is parsed once; only the active block is re‑parsed after a lightweight remend that closes unfinished syntax. The renderer then sends only the incremental patch via an onPatch callback instead of the whole tree, reducing parsing complexity from O(N²) to O(N) and decoupling transmission size from total document length.

Strategy 3: Isolated Extension Points for Custom Syntax and Components

Two injection points— extensions for custom tokenizers and components for tag‑to‑node mapping—are instance‑scoped, keeping the global marked configuration untouched. Extensions produce MiniNode directly, preserving the no‑HTML principle. Built‑in LaTeX and code‑highlight plugins, as well as user‑defined tags like <ant-button>, are supported without increasing bundle size thanks to lazy loading.

Extension Capability Comparison

Rich‑text: no custom syntax, no extensions.

towxml: syntax fixed, requires source fork for new rules.

mp‑html: plugin system works on HTML/node layer, not streaming‑friendly.

x‑markdown‑mini: token‑level extensions, direct node output, instance isolation, fully streaming compatible.

Benchmark Results

Tests on macOS 26.5.1 with Node 20 measured pure "Markdown → renderable node tree" conversion time for short (2.9 KB), medium (11.6 KB), and long (29 KB) documents. x‑markdown‑mini v1.0 outperformed towxml by 4.4× and mp‑html by 2.5× on the longest text, confirming that the advantages grow with document size.

Conclusion

@ant-design/x‑markdown‑mini addresses the three streaming bottlenecks by eliminating the HTML middle layer, caching stable blocks with incremental patching, and offering isolated, plug‑in‑based extensions. The result is a high‑performance, multi‑platform mini‑program Markdown renderer that delivers faster conversion, richer interactivity, and low‑cost extensibility.