Why redo pandoc? I love pandoc, but I kept wanting two things it can't give me: a small, embeddable binary (pandoc is well over 180 MB) and speed that makes conversion feel free.
Some numbers on an M1 Pro comparing carta 0.0.6 against pandoc 3.10 with identical flags and equivalent output, measured with hyperfine (full tables and methodology: https://github.com/mfkrause/carta/blob/main/docs/BENCHMARKS....):
commonmark -> html, 1 MB input 74 ms vs 1178 ms (~16x)
html -> json, 1 MB input 36 ms vs 1266 ms (~35x)
startup, near-empty input 2.7 ms vs 31 ms (~11x)
peak memory, 1 MB conversion 47 MB vs 246 MB
binary size 9.1 MB vs 179.8 MB (~20x)
One caveat on that last row: pandoc implements a lot of surface carta doesn't have yet, so read 20x as "where things stand today". However, most of the work that heavily affects binary size like syntax highlighting is already done, so a future version that has full parity with pandoc will still be a lot smaller.Status: early alpha (v0.0.6), API still unstable. Usable in both directions today: the full Markdown family, HTML, LaTeX, reStructuredText, Org, docx, ODT, EPUB, Jupyter notebooks, RTF, MediaWiki/DokuWiki/Jira, man pages. Write-only so far: Typst, reveal.js, Beamer, AsciiDoc. There's a full list in docs/STATUS.md.
Everything is developed and tested against pandoc 3.10's behavior. JSON filters already speak pandoc's filter protocol, so existing JSON filters should "just work"; Lua filters are the biggest missing piece.
AI disclaimer: I don't want to act like I'd be able to redo decades of JGM's work and research in a few weeks. Around 90% of the code is generated by an LLM (mostly adding new formats), but the general architecture behind it is mine, as is the testing and conformance tooling that confirms whatever a LLM does is at provable parity with pandoc and safe to use.
I'd greatly appreciate any feedback you have and hope you get the chance to try out carta!