Quarkdown, billing itself as "Markdown with Superpowers," hit v2.0 on April 23. It's a Kotlin/JVM document processing system - although the more accurate framing is that it's a typesetting language with markdown-shaped syntax, in the same family as LaTeX, Typst, or AsciiDoc rather than the GitHub- or Obsidian-flavored markdown many seem to prefer writing.
The headline pitch is single-source-multiple-output: switch a .doctype directive and the same input compiles to a paged paper, a slide deck, a docs site, or plain notes. Reactive preview, a standard library, and a real templating system round it out. The templating is the most distinctive piece:
.function {animal}
name ecosystem picture:
.row
.clip {circle}
.picture
- **Name**: .name
- **Ecosystem**: .ecosystem
.animal {Red panda} ecosystem:{Temperate forests}
That's cleaner than the LaTeX or AsciiDoc equivalents, and the reactive preview is a meaningful improvement over the edit-compile-view loop. Three things stand out about how it's positioned:
The .qd extension is not markdown. The directives are syntactically incompatible with what renders .md - GitHub, Obsidian, static site generators, most CMSes. Quarkdown isn't a markdown extension; it's a replacement language with markdown-flavored syntax. The "with superpowers" framing understates that.
It has no pegdown- or flexmark-compatible mode. For an existing markdown pipeline, Quarkdown isn't incremental adoption - it's a switch. That means Quarkdown has the same problem AsciiDoc has: presumably a superior format, but one whose potential users use a different common format and they'd have to switch to see actual benefits. Python has Sphinx with MyST, keeping .md and adding a directive layer on top, which is closer to what "markdown with superpowers" actually implies. Sphinx is also a notable omission from Quarkdown's own "Replaces..." list for the docs doctype, which names Docusaurus, MkDocs, VitePress, and GitBook but not the system that arguably owns the most serious technical-docs mindshare.
Lastly, it's not positioned as a library. The docs lead with CLI installation - curl, brew, scoop - and the embedding story isn't front and center. Given that the engine is Kotlin, a pluggable JVM-library framing ought to be straightforward, but it isn't what the project leads with. Their primary userbase probably isn't coders, given that framing, and that's fine, but it's a curious omission.
With all of that said, the template language does look well-thought-out, the site itself looks snazzy (and is, presumably, built with Quarkdown), and it's certainly always nice to see improvements in documentation processes. It doesn't cover validation from what I've seen (i.e., "Does this documentation source fit these requirements?") but that's also not a typical use case for documentation generators - it's usually bolted on.