Dev News Daily ENDE

Quarkdown adds functions and variables to Markdown

Markdown wins because it is small, and it loses for the same reason: the moment a document needs a repeated block, a computed value or a second output format, you are writing a build script around it, or you are moving to LaTeX. Quarkdown is an attempt to close that gap from the Markdown side — a superset in which functions and variables are part of the language, so repeated content becomes a one-line call rather than a copy.

The output side is the interesting half. One source compiles to several document types, selected from inside the document itself: a plain document, a paged one for papers and books, slides, or a documentation site — the project's own wiki, which runs past a hundred pages, is built this way and is quoted as compiling in a couple of seconds. HTML and PDF are both first-class, with paged output handled by paged.js and slides by reveal.js, plus Markdown and plain-text export.

It also ships the things that decide whether a tool survives contact with real use: a command-line compiler, a language server, live preview for iteration, and a documented deployment path for continuous builds. Functions are sandboxed with respect to system resources, which is the right default for a language that people will inevitably run on documents they did not write.

The repository puts a comparison table against LaTeX and the usual Markdown toolchains near the top, which tells you plainly what it is aiming at. Licensing is GPLv3 for the core, with the CLI and language server under AGPLv3.

Quarkdown adds functions and variables to Markdown
Quarkdown adds functions and variables to Markdown — Dev News Daily

What it means

The problem it names is real, and most teams solve it badly. Documentation that needs conditionals and shared fragments usually ends up as Markdown plus a templating layer plus a site generator plus a PDF step, glued together by somebody who has since left. Putting the logic inside the document language is not obviously right, but it is at least one decision instead of four.

The risk is the one every extended-Markdown project runs into: you can no longer read it with a plain reader. The value of Markdown is that everyone's editor, every code host and every static generator understands it. A superset is a private dialect — fine when one team owns the corpus, painful when contributors arrive with the expectation that their editor preview is what will be published. Look at your own repository and ask how many files would need the dialect and how many would just carry the risk.

And "Turing-complete" is a selling point that is also a warning. A document that can compute can fail to compile, loop, or produce different output on different machines — which is exactly why reproducibility tooling exists in the LaTeX world. Sandboxing system access is the right start; the next question for anyone adopting it is whether a build of the same source, on a different machine, a year from now, still produces the same PDF.

Worth a look if your documentation has outgrown Markdown and you were about to reach for LaTeX out of habit.

Written by Victoria Shinder.