Code & Markdown Presentation Frameworks — Domain Explainer#

Research Code: 1.110.6 Category: 1.110-119 User Interface & Front-End Libraries Created: 2026-05-31

The Hardware Store Analogy#

A WYSIWYG slide tool (PowerPoint, Keynote, Canva) is a pre-fab furniture store: you drag a chair into place, nudge it, and what you see is what you get. Fast for a one-off, but every chair is positioned by hand, and if you want fifty matching chairs you reposition fifty times.

A code/Markdown presentation framework is the lumber-and-hardware aisle: you write a plain-text description of the deck (“heading here, this code block there, this diagram”) and a build tool assembles it. The first cut is slower, but the cuts are repeatable — change the theme once and all fifty slides update, regenerate the PDF with one command, and keep the whole deck in Git next to the code it’s about.

That’s the whole pitch: slides as source code instead of slides as a binary blob.

What Pain Does This Solve?#

Developers giving technical talks hit specific frictions with WYSIWYG tools:

• Code on slides looks bad. Pasting code into PowerPoint loses syntax highlighting, breaks indentation, and can’t show a live diff between two versions.
• No version control. A .pptx is a binary blob — you can’t git diff it, review it in a PR, or merge a co-presenter’s changes cleanly.
• Manual consistency. Restyling a 40-slide deck means touching 40 slides by hand.
• No reproducibility. A chart baked into an image goes stale; you can’t re-run the code that produced it.
• Lock-in & portability. The deck lives in one desktop app, not as open text you can host, embed, or diff anywhere.

Code-first frameworks trade up-front authoring convenience for highlighting, diffing, theming-at-scale, version control, and web deployment — the things developers already value in their codebase.

The Core Idea (How They Work, Conceptually)#

Every tool in this space follows the same pipeline:

Source (Markdown / JSX / HTML)  ->  Build tool  ->  Slides (HTML deck, PDF, or PPTX)

A horizontal rule (---) or a slide-boundary marker splits the source into slides. A theme (CSS) controls the look. A renderer turns it into either an interactive HTML deck you present in a browser or a static file (PDF/PPTX) you hand off.

The frameworks differ mainly in how much app lives inside the deck:

• At one end, pure-Markdown converters (Marp, remark) keep it simple: text in, document out, no interactivity beyond what the renderer gives you.
• At the other end, deck-as-an-app frameworks (Slidev, Spectacle) let you embed live components, run code, animate between states, and ship the deck as a web app.

Solution Categories (Broad Approaches)#

Rather than memorize tools, recognize the four shapes:

1. Markdown-to-document converters — Markdown in, PDF/PPTX out, deterministic and boring (in the good way). Best when the deliverable is a file, not a live web app. (Marp, remark, Quarto.)

2. Component-app decks — the deck is a real front-end app; slides can hold live code, interactive widgets, and animated transitions. Best for technical talks where the slide does something. (Slidev on Vue, Spectacle on React.)

3. Plugin-platform decks — a mature, framework-agnostic HTML deck engine with a deep plugin/customization surface and a long track record. Best when you want control and longevity over batteries-included DX. (reveal.js.)

4. Spatial / canvas decks — non-linear, zoom-and-rotate “infinite canvas” instead of a slide stack. A niche but distinctive style. (impress.js.)

Those four describe the engine. A fifth pattern cuts across all of them — it changes who authors, not how the deck renders:

5. Generation pipelines — source material (a doc, an outline, a prompt) is turned into Markdown automatically (by a template, script, or LLM), then handed to one of the engines above. The author writes no code yet keeps the code-first benefits (a draftable, diffable, approvable text source; brand consistency; automation). This is how a non-developer can use these tools at all, and how decks get produced on a cadence rather than one at a time. The WYSIWYG SaaS auto-generators (Gamma, Tome — see 3.141) are the buy-instead-of-build version.

A useful tell for category 2: those engines are usually built on a build tool from 1.114 — e.g. Slidev is a Vite application, so its config and build performance are Vite’s (an architectural detail unique to it among the engines here).

Trade-Off Overview (General Pros & Cons)#

Why reach for a code-first framework:

• Beautiful, accurate code rendering (real syntax highlighters, animated code diffs)
• Plain-text source: git diff, PR review, co-authoring, long-term archival
• Theme once, apply everywhere; regenerate exports with one command
• Web-native: host it, embed it, link to a specific slide
• Reproducible content (executable code cells, generated charts) in the data-science tools

Why you might not:

• Authoring is slower for simple, image-heavy, “just make it look nice” decks
• Pixel-perfect art direction is harder than dragging boxes on a canvas
• A build step and a dev environment are required — non-developers can’t easily edit
• PPTX export is approximate; complex animations rarely survive the round-trip
• The “deck-as-an-app” tools have a real learning curve (you’re writing a small app)

When To Use vs. When Not To#

Reach for a code/Markdown framework when:

• You’re a developer presenting about code (talks, workshops, lunch-and-learns)
• The deck should live in Git alongside a repo or be reviewed in a PR
• You need accurate, possibly animated, code samples
• You’ll host the deck on the web or embed it
• Content must be reproducible (re-run the analysis, regenerate the chart)

Stick with WYSIWYG (PowerPoint / Keynote / Canva / Gamma) when:

• A non-developer needs to edit the deck
• The deck is visual/design-led, not code-led (sales, marketing, pitch decks)
• You need pixel-perfect art direction and fast manual layout
• You want zero setup and no build step
• (Those tools, the SaaS ones, are surveyed separately in 3.141.)

Rule of thumb: If your slides contain code, use a code-first framework. If your slides are the product of design work, use a design tool.

Common Gotchas#

• PPTX export ≠ PowerPoint parity. Exported PPTX is often slides-as-images or a rough approximation; animations and editability rarely survive. If the deliverable must be an editable PowerPoint, this whole category fights you.
• Fragments vs. PDF. Incremental reveals (“fragments”/“clicks”) usually expand into multiple printed pages on PDF export — expected, but surprising the first time.
• “Markdown” is a spectrum. Marp is close to plain CommonMark; Slidev’s Markdown is a heavily extended dialect with frontmatter, directives, and embedded components. Decks are not portable between tools without rework.
• The app tools are apps. Slidev/Spectacle bring a node_modules, a dev server, and a build — power and weight together.

Glossary#

• WYSIWYG — “what you see is what you get”; visual editors like PowerPoint/Keynote.
• Fragment / click — an incremental reveal step within a single slide.
• Presenter mode — a second view with speaker notes, timer, and next-slide preview.
• Frontmatter — YAML metadata at the top of a Markdown file configuring the deck.
• HMR (Hot Module Replacement) — instant in-browser updates as you edit source (a Vite feature Slidev inherits; see 1.114).
• Islands / components-in-slides — embedding live interactive UI inside a slide.

Where To Go Next#

• Choosing a tool fast? → 01-discovery/S1-rapid/README.md
• Picking a build tool / understanding Vite? → 1.114-build-tools
• Static sites, not slides? → 1.110.5-static-site-generators
• Non-code, design-led decks (SaaS)? → 3.141-presentation-design-tools

S1-Rapid: Code & Markdown Presentation Frameworks — Quick Decision Guide#

Reading time: 15 minutes

A practical guide for choosing a code-first / Markdown-based presentation framework in 2026 — the developer’s alternative to PowerPoint, Keynote, and Canva.

Table of Contents#

1. When to Use a Code-First Deck
2. Quick Selection Matrix
3. Top Recommendations by Priority
4. A Third Path: Generation Pipelines
5. Red Flags and Gotchas
6. Decision Tree
7. 30-Second Decision Table

When to Use a Code-First Deck#

Good Fit#

• You’re presenting about code — talks, workshops, conference sessions, lunch-and-learns
• The deck belongs in Git — versioned, PR-reviewed, co-authored alongside a repo
• Code rendering matters — real syntax highlighting, animated diffs, live editing
• Web deployment — you’ll host or embed the deck, or link to a specific slide
• Reproducibility — content is generated by code you can re-run (charts, analyses)

Poor Fit#

• A non-developer must edit it — no build step in their workflow
• Design-led decks — sales, marketing, pitch decks where layout is the product
• You need editable PowerPoint out — export is approximate, not true .pptx parity
• Zero setup required — you don’t want a node_modules or a dev server

For design-led / WYSIWYG SaaS tools (Canva, Beautiful.ai, Gamma, Pitch), see 3.141-presentation-design-tools. This survey covers only code/Markdown libraries. > The “non-developer” line isn’t absolute. A generation pipeline (material in → auto-structured Markdown → rendered by any engine below) lets a non-coder drive these tools without writing code. See A Third Path.

Quick Selection Matrix#

* Marp’s star count is split across marpit / marp-core / marp-cli; the ecosystem is larger than the core-engine number suggests. reveal.js leads raw popularity (~18.5k npm weekly downloads); Slidev leads developer-talk mindshare.

Legend — Code Rendering: ⭐ Best = animated code diffs + live editing; Good = accurate static highlighting; Basic = generic highlighter.

Top Recommendations by Priority#

#1 Developer Technical Talk (live code, animations, web deploy)#

Choose: Slidev

• Built on Vue 3 + Vite → instant HMR, full plugin API (see 1.114)
• Best-in-class code presentation: Shiki highlighting, Shiki Magic Move (animated transitions between code states), TwoSlash type-on-hover, embedded Monaco for live edits
• Authoring is a single extended-Markdown file; drop in Vue components for interactivity
• Batteries included: KaTeX (math), Mermaid (diagrams), Iconify (icons), drawing/annotation, RecordRTC recording + camera view, presenter mode
• Exports to PDF, PPTX, PNG, or a static SPA

When not Slidev: non-developers must edit it, or you need a deterministic file pipeline with no app weight → use Marp.

#2 Repeatable Docs / Training Decks (Markdown → PDF/PPTX)#

Choose: Marp

• Pure CommonMark + CSS themes — the lowest-friction, most portable Markdown
• Deterministic CLI: Markdown → HTML / PDF / PPTX / PNG with one command
• Excellent VS Code live-preview extension (enhanced in 2026)
• The pragmatic pick when the deliverable is a file and consistency/repeatability win

When not Marp: you want live code, embedded components, or rich animations → Slidev.

#3 Maximum Control / Long-Lived Infrastructure#

Choose: reveal.js

• The most-starred, longest-lived HTML deck engine (~70k stars)
• Deep plugin ecosystem, auto-animate, fragments, a JavaScript API, remote control
• HTML-first authoring (optional Markdown), framework-agnostic
• The safe choice for embedded/kiosk displays, custom web behavior, and decks you’ll maintain for years

Note: Quarto and many other tools render to reveal.js — choosing reveal.js is also choosing a stable output target.

#4 React Teams#

Choose: Spectacle — decks authored as React/MDX components, living inside your existing React toolchain. Pick it when your team already thinks in JSX.

#5 Data-Science / Academic Reproducibility#

Choose: Quarto (revealjs output) — Markdown (.qmd) with executable R/Python/Julia cells, so charts and tables are regenerated from code at build time. The successor to R Markdown for reproducible decks.

#6 Niche: Spatial / Zoom Presentations#

Choose: impress.js — Prezi-style infinite-canvas zoom-and-rotate. Distinctive, but basic docs and a steeper layout model; use only when the spatial style is the point.

A Third Path: Generation Pipelines#

The survey’s framing so far is binary — code-first engines (this survey) vs. WYSIWYG SaaS (3.141). There’s a third, increasingly important pattern that dissolves the binary:

Generation pipeline: source material (a doc, an outline, a prompt) → an automated step (template, script, or LLM) emits Markdown → a code-first engine below renders the deck.

Why it matters: the author never writes code, yet still gets the code-first advantages — plain-text source you can draft, diff, and approve before it becomes a deck, brand-CSS consistency, web-native output, and automation. It’s how one engine can serve both a developer and a non-developer audience, and how a team can produce decks (and social cards) on a repeatable cadence rather than one at a time.

What this changes for tool choice: pick the engine for its render and export properties, not its authoring ergonomics — because in a pipeline a machine does the authoring. That favors Markdown-native, deterministic, wide-export engines:

WYSIWYG auto-generators (Gamma, Tome — see 3.141) are the SaaS form of this idea, but they discard the Markdown source of truth and the branding/automation control. If you want a non-coder interface and a code-first backend, build the pipeline over Marp/reveal.js rather than buying the SaaS.

Engine ↔ Build-Tool Coupling (a note on Slidev + Vite)#

One architectural detail worth flagging because it surprises people: Slidev is itself a Vite application. Most engines here are self-contained, but Slidev compiles your deck to a Vue 3 + Vite web app — so customizing it deeply means working with Vite’s config/plugin system, and its build performance tracks Vite’s (now Vite 8 + Rolldown — see 1.114-build-tools). This is a point in Slidev’s favor (it rides a fast, well-funded toolchain) and its cost (the heaviest toolchain and authoring lock-in in the set). No other engine here has this coupling.

Red Flags and Gotchas#

• PPTX export is approximate. Expect slides-as-images or a rough conversion; animations and editability rarely survive. If you need a truly editable PowerPoint, this category fights you — author in PowerPoint instead.
• Fragments explode in PDF. Incremental reveals print as multiple pages (reveal.js does this by default). Expected, but plan for it when sharing PDFs.
• Decks are not portable between tools. Slidev’s extended Markdown ≠ Marp’s CommonMark ≠ reveal.js HTML. Switching tools means rewriting.
• “It’s just Markdown” oversells the app tools. Slidev and Spectacle bring a build step and real complexity. The lightweight promise applies to Marp/remark, not the app decks.
• Star counts mislead. reveal.js wins raw stars/downloads partly through age; Slidev wins new developer-talk adoption. Pick by output need, not the leaderboard.

Decision Tree#

Is the deck about CODE / a developer talk?
├─ NO → Use a design tool (PowerPoint/Keynote/Canva/Gamma) → see 3.141. Stop.
└─ YES
   ├─ Need live code, animated diffs, embedded components, web deploy?
   │   └─ Slidev   (Vue 3 + Vite; best code rendering)
   ├─ Just need Markdown → a clean PDF/PPTX file, repeatably?
   │   └─ Marp     (pure Markdown + CSS, deterministic CLI)
   ├─ Need maximum control / plugins / a decade-stable HTML engine?
   │   └─ reveal.js
   ├─ A React team wanting decks as components?
   │   └─ Spectacle
   ├─ Reproducible data-science / academic deck (executable code cells)?
   │   └─ Quarto (revealjs)
   └─ Prezi-style spatial/zoom canvas?
       └─ impress.js

30-Second Decision Table#

Sources#

• PkgPulse — Slidev vs Marp vs reveal.js 2026: Code-First Presentations
• dasroot — Markdown-Based Presentation Tools: Marp, Slidev, reveal.js (Apr 2026)
• Slidev — Why Slidev · slidevjs/slidev (GitHub)
• reveal.js — official site · PDF Export
• npm trends — marpit vs mdx-deck vs reveal.js vs spectacle vs remark
• Quarto — Reveal.js presentations
• Sharayeh — Markdown to Slides: Marp vs Slidev (Tested, 2026)
• Fru.dev / Medium — 10 Code-Based Presentation Tools for Developers, Ranked

S1-Rapid: Research Approach#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S1 — Rapid Discovery Date: 2026-05-31 Time invested: ~30 min (rapid pass)

Objective#

Map the landscape of code-first / Markdown-based presentation frameworks a developer would npm install and author as source — answering “WHAT exists and WHICH do I pick?” at shopping-comparison altitude — category-first, weighting all 7 tools by fit rather than spotlighting any one. The Slidev↔Vite coupling is noted as an architectural fact (cross- referenced to 1.114), not as a headline.

Scope Decisions#

• IN: open-source libraries/CLIs — Slidev, reveal.js, Marp, Spectacle, impress.js, remark, Quarto (revealjs output).
• OUT: WYSIWYG SaaS slide builders (Canva, Beautiful.ai, Gamma, Pitch) — covered in 3.141. Test applied: does a developer author this as installable source? If no → out.

Method#

1. Comparative web search across 2026 sources (PkgPulse, dasroot, Sharayeh, npm trends, official docs, Hacker News, vendor “why” pages).
2. Popularity signals via GitHub stars + npm weekly downloads (npm trends).
3. Triangulated each tool’s authoring model, stack, code-rendering quality, and export targets from official docs + independent comparisons.
4. Organized findings into four philosophies (converter / component-app / plugin-platform / spatial) rather than a flat list, to make selection mechanical.

Confidence & Limitations#

• High confidence: tool categories, authoring models, export capabilities, the Slidev↔Vite relationship.
• Medium confidence: exact star/download numbers (drift quickly; Marp’s are split across packages). Treat as order-of-magnitude.
• Not yet done (future passes): S2 technical deep-dive (theming internals, plugin architecture, build performance), S3 personas, S4 long-term viability. This is an S1 rapid pass only.

S1-Rapid: Recommendations#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S1 — Rapid Discovery

The 30-Second Summary#

1. Default for developer talks: Slidev — best code rendering (Shiki Magic Move, Monaco live editing), Vue 3 + Vite, presenter mode, web deploy.
2. Markdown → file (PDF/PPTX), repeatably: Marp — pure CommonMark + CSS, deterministic CLI.
3. Maximum control / longevity: reveal.js — biggest, oldest, deepest plugin ecosystem.
4. React teams: Spectacle — decks as JSX/MDX components.
5. Reproducible data-science decks: Quarto — executable code cells → reveal.js.
6. Spatial/zoom style: impress.js (niche).
7. Non-developer or design-led deck: leave this category — use a WYSIWYG SaaS tool (3.141).

Universal Truth#

If your slides contain code, use a code-first framework; if your slides are the product of design work, use a design tool. Within code-first, the axis is deliverable: a live web app (Slidev / reveal.js) vs. a deterministic file (Marp / Quarto).

Authoring Path Note#

For non-developer audiences, don’t stop at “use a design tool.” A generation pipeline (material → auto-structured Markdown → rendered by Marp/reveal.js/Slidev) puts a no-code interface over these engines while keeping a draftable, brandable, automatable source. Prefer Marp as the pipeline’s render target (plainest Markdown, widest export); reach for Slidev only if the pipeline needs live code.

Engine Coupling Note#

Among these engines, Slidev alone is coupled to a build tool — it’s a Vite application, so its config and build performance are Vite’s (see 1.114-build-tools, refreshed for Vite 8

• Rolldown). A point in its favor (fast, well-funded toolchain) and its cost (heaviest setup, highest lock-in). Noted as an architectural fact, not a recommendation to prefer it.

Strategic Notes#

• Don’t choose on stars. reveal.js leads raw popularity through age; Slidev leads new developer-talk adoption. Match the tool to the output you need.
• Watch PPTX expectations. None of these produce truly editable PowerPoint; if a stakeholder needs .pptx they can edit, set expectations early.
• Portability is low. Committing to a tool’s authoring dialect is a real lock-in; the decks don’t transfer without rework.

Suggested Next Passes#

• S2 (comprehensive): theming systems, plugin architecture, Slidev’s Vite plugin surface, build performance, code-rendering internals (Shiki/Magic Move).
• S3 (need-driven): personas — conference speaker, internal trainer, data scientist, open-source maintainer, React product team.
• S4 (strategic): maintainer health, release cadence, backing (Slidev/antfu ecosystem, reveal.js maturity), 3–5 year viability and migration risk.

S2-Comprehensive: Technical Architecture Deep-Dive#

Reading time: 45-60 minutes

How code/Markdown presentation frameworks actually work — runtime, authoring pipeline, code-rendering internals, theming, plugins, and export. Facts current as of May 2026.

Table of Contents#

1. The One Axis That Matters: Code Rendering
2. Architecture by Tool
3. Slidev ↔ Vite: How the Engine Works
4. Cross-Cutting Comparison Tables
5. Export Pipelines

The One Axis That Matters: Code Rendering#

For a code presentation tool, the syntax-highlighting engine is the central architectural fork. Everything else (theming, transitions) is comparable across tools; code rendering is not.

Shiki is why Slidev’s code looks like your editor and why it can do animated code diffs (Magic Move) — tokenization happens ahead of time, so token identity is known and can be animated. Runtime highlighters can’t easily do that. This single choice cascades into Slidev’s whole “deck-as-an-app” identity.

Architecture by Tool#

Slidev — Vue 3 + Vite app generator#

• Runtime: each deck compiles to a Vue 3 SPA; Vite is the dev server and bundler; UnoCSS (on-demand atomic CSS) is the styling engine. Created by Anthony Fu (antfu), who also maintains core pieces of Vite/Vue/UnoCSS/Shiki — hence the tight coupling.
• Authoring: a single slides.md. --- separates slides; per-slide YAML frontmatter doubles as config (layout:, transition:, clicks:, class:). Markdown is Vue-powered (via vite-plugin-vue-markdown + markdown-it): drop raw HTML or .vue components inline.
• Code rendering (the differentiator):
  • Shiki build-time tokenization, dual light/dark themes.
  • Shiki Magic Move — Keynote-style morphing between code states. Wrap successive blocks in a magic-move container, bound to the clicks system. Internally: runs Shiki twice, pairs tokens with Google diff-match-patch (Move/Enter/Leave), animates Moves with the FLIP technique, fades Enter/Leave. (antfu.me)
  • Per-click line highlighting: {1|2-3|all} steps through highlights on click.
  • Monaco editor (```ts {monaco}) and Monaco Runner ({monaco-run}) that executes JS/TS in-browser (unsandboxed by default), with automatic type acquisition via @typescript/ata. (sli.dev/features/monaco-run)
  • TwoSlash: runs the TS compiler at build time to inject real types/errors into code.
• Theming: themes are npm packages (theme: name); layouts are Vue components; global layers (global-top.vue, global-bottom.vue) persist across slides.
• Plugins: two layers — Vite plugins (low-level) and Slidev addons (npm packages). Six Vite plugins are injected internally; you configure them via slidev.* fields, never re-add them.
• Animation: clicks are the atomic unit (v-click, v-clicks, v-after, at="+2"); v-motion (via @vueuse/motion); slide transitions built on the View Transitions API.
• Gotchas: PPTX exports as images (no editable text); export needs a separate playwright-chromium install; heaviest toolchain in the set; Monaco runner is unsandboxed.

reveal.js — vanilla-JS plugin engine (the substrate)#

• Runtime: plain JavaScript, no UI framework. Walks <section> elements in .reveal > .slides, managing state via CSS classes/transforms. Nested <section>s give signature 2D navigation. v6.0 line; build migrated to Vite.
• Authoring: HTML-first; Markdown is a plugin (data-markdown, ---/-- separators), not the native model. Per-slide config via data-* attributes.
• Code rendering: highlight.js plugin; line numbers + step-through highlight via data-line-numbers="1|2-3|4" (pipe = click steps). No built-in code morphing (approximate via auto-animate) and no Monaco/live-run.
• Theming: SCSS-compiled CSS themes (black, white, league, dracula, …); swap by stylesheet.
• Plugins: lightweight registry (Reveal.initialize({plugins:[...]})); built-ins Markdown, Highlight, Math, Notes, Search, Zoom; large third-party ecosystem (chalkboard, menu, …).
• Animation: fragments (.fragment, data-fragment-index); Auto-Animate (data-auto-animate on adjacent sections matches by data-id/text/src/DOM order and animates most CSS props). (revealjs.com/auto-animate)
• Export: print CSS — open with ?print-pdf, then browser “Save as PDF” (Chromium). pdfSeparateFragments controls whether each fragment becomes its own page. No built-in headless exporter; DeckTape (Puppeteer) is the common external tool.
• Why it matters: reveal.js is a substrate — Quarto and many MD→HTML pipelines render to it. Its stability underwrites other tools.

Marp — Marpit engine, static HTML/CSS out#

• Runtime: Marpit is a markdown-it-based engine that emits static HTML + CSS — no per-slide JS state machine. Marp Core adds practical syntax, themes (default/gaia/uncover), auto-fit, emoji, and highlight.js. Distinctive inline-SVG slide mode wraps each slide in <svg><foreignObject> for pixel-perfect CSS-only scaling.
• Authoring: CommonMark with a hard rule — extensions must never break CommonMark, so a deck still renders in a plain Markdown viewer. Directives (global vs local; YAML frontmatter or HTML-comment form; underscore-prefixed _class for single-slide scope).
• Code rendering: highlight.js; theming code colors requires CSS overloading inside the theme (hljs @import doesn’t work because styles are scoped per slide — a known friction point). Static output → no animated diffs, no Monaco, weak per-click control.
• Theming: pure CSS (section = a slide); no predefined classes/mixins.
• Export: Marp CLI drives headless Chrome via puppeteer-core (reuses your Chrome) → PDF/PNG/JPEG. PPTX defaults to image-per-slide; experimental --pptx-editable uses LibreOffice for editable output (lower fidelity, no notes — not recommended for design-critical decks). (marp-cli)
• Strength: lowest operational cost; --watch/--server; excellent VS Code preview.

Spectacle — React component library#

• Runtime: React. Deck manages state/navigation; Slide containers; MarkdownSlide/ SlideLayout templates. CSS-in-JS styling (Emotion historically; recent docs reference styled-components — verify against current package.json).
• Authoring: JSX primary (<Deck><Slide>…), plus Markdown/MDX via spectacle-mdx-loader (webpack + remark/rehype). spectacle-cli serves .md/.mdx.
• Code rendering: CodePane uses react-syntax-highlighter (Prism); line highlighting/ stepping via highlightRanges + the Appear/Stepper system. No Monaco/live-run, no morphing.
• Theming: themes are JS objects overriding the default (screen + print). Bring styled-components/emotion.
• Animation: Appear (progressive reveal) and Stepper; transitions via react-spring; full React interactivity. Presenter mode syncs windows via broadcast-channel.
• Export: built-in print/PDF via the browser print path (React-rendered DOM).
• Gotchas: JSX is verbose vs Markdown; deepest non-portable lock-in (no Markdown exit path); see S4 for the serious maintenance concern.

impress.js — CSS3 spatial canvas (the outlier)#

• Runtime: vanilla JS on CSS3 3D transforms. Positions/rotates/scales .step elements in a 3D space; the “camera” flies between steps. Requires CSS 3D transform support.
• Authoring: HTML only — each step uses data-x/-y/-z, data-rotate-*, data-scale. No Markdown, no frontmatter.
• Code rendering: none built-in (hand-add highlight.js). Not a code-deck tool.
• Animation: step classes .future/.present/.past; substep plugin for fragment-like reveals. The animation is the camera flight — its entire identity.
• Export: none native (DeckTape; 3D rarely exports cleanly).
• Use only when the spatial relationship itself carries meaning.

remark (gnab) — single-file in-browser Markdown#

Disambiguation: this is gnab/remark (the slideshow), NOT remarkjs/remark (the Markdown AST processor in the unified.js ecosystem). Same name, different project. The AST processor is alive; the slideshow is dormant (see S4).

• Runtime: a single JS file, zero build. A <textarea> (or remote .md) is rendered client-side by remark.create() into scaled slides.
• Authoring: Markdown; --- slide separator, -- for incremental; signature content-classes syntax .left[…]/.center[…] wraps content in a CSS class (the mechanism R’s xaringan exposes).
• Code rendering: highlight.js; basic. No Monaco/morphing.
• Export: none native (browser print / DeckTape). Presenter mode with cloned window + notes.

Quarto — Pandoc → reveal.js publishing pipeline#

• Pipeline: .qmd → (optional code execution via Jupyter/knitr) → Pandoc AST → reveal.js HTML. Runtime is reveal.js; Quarto adds Pandoc templates, post-processing, and its own reveal plugins. By Posit (formerly RStudio).
• Authoring: Pandoc Markdown; headings define slides (# section, ## slide; slide-level configurable); fenced divs (::: {.fragment}) for reveal features.
• Code rendering: executable code (R/Python/Julia/Observable) is the killer feature — output-location places results (fragment/column/slide). Highlighting via Skylighting by default; step-through via code-line-numbers="1|2-3". “Live” = pre-executed results, not an in-slide editor.
• Theming: 11 built-in themes; custom via SASS layers (polished, Bootstrap-adjacent).
• Diagrams/math: Mermaid + Graphviz first-class (compile-time) — an edge over raw reveal; KaTeX/MathJax math. Caveat: speaker-notes divs can’t depend on Mermaid.
• Export: reveal HTML primary; PDF via reveal ?print-pdf; PPTX is a separate native Pandoc output (not via reveal). Heaviest install (Quarto CLI + Pandoc + kernels); build cost dominated by code execution.

Slidev ↔ Vite: How the Engine Works#

Slidev is the one engine here coupled to a build tool, so its architecture deserves a closer look (the others are self-contained). The Vite relationship in detail:

• Slidev is a Vite app generator. The CLI boots a ViteDevServer and compiles the deck to a Vue SPA for build. Your vite.config.ts is merged with config from Slidev core + theme + addons.
• Six internal Vite plugins are pre-installed: @vitejs/plugin-vue, unplugin-vue-components, unplugin-icons, vite-plugin-vue-markdown, vite-plugin-remote-assets, unocss/vite. You tune them via slidev.* namespaced options — re-declaring them breaks the build.
• Markdown is a Vite plugin (vite-plugin-vue-markdown), so customizing Markdown = configuring a Vite plugin (markdownItSetup).
• HMR is what makes editor→slide updates instant and stateful.

Vite 8 + Rolldown (2026) for Slidev users: Vite 8 stable (March 2026) replaces esbuild-dev/ Rollup-prod with the single Rust bundler Rolldown (10–30× faster builds; Rolldown 1.0 stable May 2026), under VoidZero (Evan You’s company — antfu’s orbit). Because Rolldown keeps the Rollup/Vite plugin API, Slidev’s internal plugins migrate without rewrites: faster slidev build and cold dev starts essentially for free, no authoring changes. Slidev is likely an early adopter given shared maintainers. (See 1.114-build-tools for the engine detail.)

Cross-Cutting Comparison Tables#

Code presentation:

Runtime / authoring:

Math / diagrams built-in: Slidev (KaTeX + Mermaid + PlantUML), Quarto (KaTeX/MathJax + Mermaid + Graphviz), Marp (math), reveal.js (Math plugin; Mermaid third-party), others manual.

Export Pipelines#

The PPTX reality: no tool produces truly editable, design-grade PowerPoint. Marp’s editable export is experimental/low-fidelity; Slidev’s is rasterized; Quarto’s PPTX comes from Pandoc (native but a different layout engine than its reveal slides). If an editable .pptx is the hard requirement, author in PowerPoint.

Fragments → PDF pages: incremental reveals expand to multiple printed pages (reveal.js pdfSeparateFragments, Slidev --with-clicks). Expected; plan for it.

Verification Caveats#

A few details from secondary sources, flagged for confirmation before deeper passes:

• Spectacle’s current CSS-in-JS library (Emotion vs styled-components) — sources conflict.
• Marpit render() API shape and the exact spot-directive list.
• reveal.js exact MathJax 4 built-in status.
• Quarto’s default highlighter in slide context (Skylighting vs reveal highlight.js). Per-slide render-speed micro-benchmarks circulating online are single-source and treated as illustrative only, not cited as authoritative.

Sources#

Slidev — Why · config-vite · Monaco run · animations · exporting · Shiki Magic Move (antfu) · shiki-magic-move repo · reveal.js code · auto-animate · plugins · PDF export · Marpit · Marp CLI · Spectacle · impress.js docs · remark · Quarto revealjs · Vite 8 beta · Rolldown 1.0

S2-Comprehensive: Research Approach#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S2 — Comprehensive (technical architecture) Date: 2026-05-31

Objective#

Answer “HOW do they work?” at the architecture level for all 7 tools, with code-rendering internals as the primary differentiator (the reason this category exists for developers).

Dimensions Examined (per tool)#

1. Rendering/runtime architecture
2. Authoring model (Markdown dialect / HTML / JSX)
3. Code-presentation internals (highlighter engine, animated diffs, live editing)
4. Theming system
5. Plugin/extension architecture
6. Export pipeline internals
7. Interactivity / animation model
8. Math/diagrams support
9. Build performance / dev server (HMR)
10. Architecture-level limitations

Plus a dedicated Slidev ↔ Vite deep-dive (config merging, internal plugins, HMR, and the Vite 8 + Rolldown impact), per the requestor’s interest.

Method#

Primary documentation (sli.dev, revealjs.com, marp.app, Quarto docs, GitHub READMEs/ DOCUMENTATION.md), plus maintainer writeups (antfu’s Shiki Magic Move post) and architecture summaries. Findings triangulated across primary + independent sources.

Confidence#

• High: highlighter engines, authoring models, Magic Move/Monaco mechanics, export engines, the Slidev/Vite relationship and Vite 8/Rolldown impact.
• Medium / flagged for verification: Spectacle’s current CSS-in-JS lib; Marpit render() API shape and exact spot-directive list; reveal.js MathJax 4 built-in status; Quarto’s default slide-context highlighter. These are noted inline in the README and don’t affect the selection conclusions.
• Excluded as unreliable: circulating per-slide render-speed micro-benchmarks (single-source, odd hardware framing) — treated as illustrative only.

S2-Comprehensive: Technical Recommendations#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S2 — Comprehensive

Architecture-Driven Verdicts#

Best code-rendering architecture → Slidev. Shiki (build-time TextMate tokenization) plus Magic Move (token-paired FLIP animation) plus Monaco (live in-browser execution) is a genuinely different class from the runtime-regex highlighters every other tool uses. If accurate, animated, or runnable code is the point, the architecture decides it.

Most durable substrate → reveal.js. A vanilla-JS, dependency-light engine that other tools (Quarto) render to. Low authoring lock-in, stable API. The architectural “safe foundation.”

Simplest, most portable pipeline → Marp. Static HTML/CSS out, CommonMark-safe input, headless-Chrome export. Nothing to break at runtime; deterministic. The architecture optimized for files, not apps.

Only reproducible-execution architecture → Quarto. Pandoc + kernel execution is unique here: outputs are regenerated from code at render time. Heaviest pipeline, but nothing else does it.

React-native architecture → Spectacle. Decks as React component trees. Architecturally sound for React teams; see S4 for the maintenance caveat that tempers this.

Key Architectural Trade-offs#

The Slidev → Vite Conclusion#

Slidev’s architecture is inseparable from Vite: customizing it deeply means working with Vite’s plugin/config system, and its build performance tracks Vite’s. The Vite 8 + Rolldown shift (Rust bundler, 10–30× faster, plugin-API compatible) benefits Slidev users with no authoring changes — a strategically favorable dependency. A Slidev investment is partly a Vite investment; read 1.114-build-tools alongside this.

What S2 Could Not Settle (defer to S3/S4)#

• Which tool for whom — a function of team, workflow, and output, not architecture → S3.
• Which tool is safe for 3–5 years — maintenance/backing, not design → S4 (and S4 materially changes the Spectacle and remark/impress.js picture).

S3-Need-Driven: Use Cases & Personas#

Reading time: 30-40 minutes

WHO needs a code-first deck, and WHY — matched to the right tool. This is the decision layer: find the persona closest to you, then read the switch-triggers.

Table of Contents#

1. Eight Personas
2. Requirement → Tool Decision Matrix
3. Team vs. Solo
4. Anti-Pattern: When to Leave This Category

Eight Personas#

1. Conference speaker, technical talk with live code → Slidev#

WHO: Developer advocate, framework author, or senior engineer giving a 30–45 min talk (KubeCon, JSConf, PyCon). Comfortable with npm/Vite tooling.

Context: Code must look alive, not screenshotted. Wants step-by-step reveals, editor-grade highlighting, possibly live editing on stage. Talk is recorded; slides published afterward.

WHY not PowerPoint: Pasting code loses accurate highlighting, can’t animate diffs, can’t run anything. Slidev’s Shiki highlighting, Magic Move (animated diffs), TwoSlash (TS types on hover), and embedded Monaco for live coding simply don’t exist in PowerPoint.

Why Slidev: The documented default for exactly this persona. Vite HMR for instant preview, embeddable Vue components, deploy as a static site. Adoption signal: Slidev’s showcase features Anthony Fu’s “Composable Vue” (VueDay), Vue maintainers, and talks at KubeCon China 2024/2025, PyCon APAC, FOSSASIA — strong Vue-ecosystem gravity.

Switch if: R/Python data talk with regenerated charts → Quarto; want a single zero-build HTML file → reveal.js/remark; a React shop reusing components → Spectacle; design-led keynote → PowerPoint/Canva.

2. Internal trainer / dev-rel, repeatable decks → PDF/PPTX → Marp#

WHO: Enablement lead or dev-rel producer shipping recurring training (onboarding, security, sprint reviews) that stakeholders consume as PDF or PowerPoint.

Context: Many decks, many editors, hand-off to non-technical stakeholders expecting .pptx/ .pdf. Branding consistency matters; generation should be automated.

WHY not PowerPoint: They author faster in diffable Markdown — but the output must be PPTX/PDF. Marp is the only tool whose first job is Markdown → PDF/PPTX/HTML/images with the widest export range and lowest operating cost.

Why Marp: “Pragmatic choice for docs teams and internal training.” Marp CLI drops into CI/CD for batch export, brand enforcement, and region-specific decks; VS Code gives live preview + one-click export.

Switch if: need live interactivity/components → Slidev/reveal.js; executable charts → Quarto; high-stakes design-led exec deck → native PowerPoint. (Caveat: Marp PPTX is typically slides-as- images, not editable native shapes — verify before betting a high-visibility deck on it.)

3. OSS maintainer / docs author, slides in the repo (docs-as-code) → Marp / reveal.js / remark#

WHO: Open-source maintainer or technical writer treating slides as docs-as-code: decks committed alongside source, reviewed in PRs, linted in CI.

WHY not PowerPoint: Binary .pptx doesn’t diff, merge, or get code-reviewed. The whole docs-as- code pattern (plain text, version control, PR review, CI linting) only works with text-source decks — the canonical reason this category exists.

Why these: Marp (cleanest Markdown + CI export), reveal.js (if already web/JS and wants longevity + plugins), remark (single self-contained HTML file, zero build — but note its dormant maintenance, see S4; fine for stable/simple needs, risky long-term).

Switch if: Vue + live demos → Slidev; executable analysis → Quarto.

4. Data scientist / academic, reproducible decks with executable charts → Quarto#

WHO: Researcher, statistician, or data scientist presenting analyses in R/Python/Julia/Observable that must be regenerable from data.

WHY not PowerPoint: Reproducibility. Quarto slides are executable documents — code runs at render and outputs are auto-inserted; PowerPoint forces manual chart copy-paste that silently goes stale. Quarto also gives native citations, cross-refs, and LaTeX math.

Why Quarto: The only tool built around executing embedded code at render time; single .qmd → reveal slides, PDF, PPTX, HTML. Documented real migration trend from Beamer/LaTeX to Quarto reveal.js (2025 academic blogs/workshops). Slide output is reveal.js, inheriting its presenter tooling.

Switch if: pure software talk with live app-code editing → Slidev; hand-crafted HTML control with no code execution → raw reveal.js; institution mandates Beamer → stay.

5. React product team, decks-as-components → Spectacle#

WHO: Front-end team already on React (JSX/MDX, a design system) wanting decks from their existing component library.

WHY not PowerPoint: Reuse production components and live-demo real code inside the deck — impossible in PowerPoint; JSX matches their daily workflow.

Why Spectacle: The only React-native tool here (Slidev is Vue). Slides are React components; templates act like Keynote masters; supports single-file, Markdown/MDX, and full React projects. (Caveat: see S4 — Spectacle’s maintenance has stalled; the case rests on “we’re already deep in React,” not momentum.)

Switch if: Vue shop → Slidev; want Markdown simplicity → Marp; need PPTX handoff → Marp.

6. Engineering manager, standardized branded decks at scale → Marp (+ CI)#

WHO: EM or platform/enablement team standardizing internal deck production (sprint reviews, architecture proposals, all-hands) for consistency and low effort.

WHY not PowerPoint: Centralized theming + CI enforcement. A shared CSS theme + Marp CLI in CI guarantees on-brand, reviewable decks; PowerPoint brand-drift can’t be linted or diffed.

Why Marp: Lowest operating cost, strongest multi-writer story, CI batch export with brand enforcement, low author-training cost. (Slidev’s training cost rises with team size — wrong direction for this persona.) reveal.js is the heavier alternative if the org wants a long-lived, deeply customized presentation platform with web devs to maintain it.

7. Educator / bootcamp instructor, recurring code-heavy decks → Slidev or Quarto; Marp for lecture notes#

WHO: Instructor delivering the same curriculum repeatedly with lots of code, revised each cohort, published for students.

WHY not PowerPoint: Accurate highlighting, incremental code reveals, live editing during lecture, and diffable source easy to update each term; students get a clean web deck, not a stale .pptx.

Why these: Slidev for web/JS/TS or live coding (Magic Move/Monaco are pedagogically strong); Quarto for data-science/CS where outputs derive from executable code (same source → notes, site, slides); Marp when lectures are mostly prose + occasional code with PDF handouts.

8. Presenter wanting Prezi-style spatial decks → impress.js#

WHO: Speaker wanting a non-linear zooming/rotating “journey across a canvas” — the open-source answer to Prezi.

WHY not PowerPoint/Prezi: PowerPoint can’t do true infinite-canvas zoom; Prezi is SaaS (subscription, lock-in). impress.js gives the effect as a free, version-controllable HTML file via CSS3 transforms.

Why impress.js: It owns the spatial/zoom niche — nothing else here does infinite-canvas natively. (Caveats: positioning-by-hand via data attributes, not Markdown; frozen since v2.0.0/2022, see S4; spatial gimmickry can hurt comprehension — use only when the spatial relationship carries meaning.)

Requirement → Tool Decision Matrix#

Team vs. Solo#

• Solo, high-polish, live code → Slidev (one expert; training cost rises with team size).
• Many writers, mixed skill → Marp (cheapest to operate, best multi-writer Markdown story).
• Web-dev team, long-lived platform → reveal.js.
• React team → Spectacle (reuse components/CI).
• Research/teaching group needing reproducibility → Quarto.
• Handoff rule: Slidev needs Node/Vite/Vue comfort; Marp wins when many people just edit Markdown; reveal.js wins when web devs own it.

Anti-Pattern: When to Leave This Category#

All seven tools share one failure mode. Use a WYSIWYG SaaS tool (PowerPoint / Canva / Pitch / Prezi — see 3.141) when:

• The author is non-technical. Markdown/JSX/HTML + CSS-for-layout is explicitly unsuitable for non-developers; a marketer or exec assistant will be slower and more frustrated than in Canva.
• Design/branding is the deliverable, not the code. Investor pitches, sales decks, visually-driven keynotes — markdown slides “feel too plain”; custom layouts require CSS, making design work slower.
• Data-heavy boardroom decks where PowerPoint’s native chart/animation tooling wins.
• A design/marketing team is in the review loop expecting visual WYSIWYG collaboration → Canva/ Figma/Pitch, not a Vite dev server.

The dividing line: code-first tools optimize for accurate code, reproducibility, diffability, and automation; SaaS design tools optimize for visual polish, non-technical authoring, and brand storytelling. Choose by which axis dominates the deck’s purpose.

Sources#

Slidev showcases · PkgPulse comparison · Marp CLI · Beamer→Quarto migration · Quarto for research · Spectacle · impress.js · Markdown vs PowerPoint · docs-as-code

S3-Need-Driven: Research Approach#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S3 — Need-Driven (personas & use cases) Date: 2026-05-31

Objective#

Answer “WHO needs this and WHY?” — map real-world personas to the right tool, with explicit switch-triggers. This is the decision layer, NOT implementation (no code).

Method#

Grounded personas in real adoption signals (Slidev showcase talks, Beamer→Quarto migration write-ups, docs-as-code practice) rather than inventing archetypes. Each persona states WHO, context/constraints, WHY-not-PowerPoint, the tool fit, and what flips the decision.

Personas Developed (8)#

1. Conference speaker, live code → Slidev
2. Internal trainer / dev-rel, repeatable PDF/PPTX → Marp
3. OSS maintainer, docs-as-code → Marp / reveal.js / remark
4. Data scientist / academic, reproducible charts → Quarto
5. React product team, decks-as-components → Spectacle
6. Engineering manager, standardized branded decks at scale → Marp (+CI)
7. Educator / bootcamp instructor → Slidev / Quarto / Marp
8. Spatial / Prezi-style presenter → impress.js

Plus an explicit anti-pattern routing non-technical / design-led decks out of this category to the 3.141 SaaS survey.

Confidence & Flags#

• High: the persona→tool mappings and switch-triggers (well-supported by sources).
• Flagged: Marp PPTX fidelity for complex layouts (likely image-based, not editable shapes); Spectacle’s lower momentum (case rests on “already React,” not popularity); remark/impress.js maintenance status (covered in S4). These are surfaced inline as caveats.
• Excluded: specific render-speed benchmarks (single unreliable source).

S3-Need-Driven: Recommendations#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S3 — Need-Driven

Match Your Situation#

The Two Decisive Questions#

1. Do your slides contain code? No → leave this category (3.141). Yes → continue.
2. Is the deliverable a live web app or a file?
   • Web app, rich/interactive → Slidev (Vue) / Spectacle (React) / reveal.js (control)
   • Deterministic file (PDF/PPTX) → Marp (simple) / Quarto (reproducible)

Persona-Level Insights#

• Marp is the most broadly-recommended tool across personas — it wins trainer, docs-as-code, and EM-at-scale because of low operating cost and multi-writer Markdown. It is the safe default unless you specifically need live code (Slidev) or reproducibility (Quarto).
• Slidev wins the single highest-value persona (the recorded conference talk) decisively — no other tool matches Magic Move + Monaco for live code.
• Quarto is non-substitutable for its persona: nothing else executes embedded code.
• Team size flips Slidev→Marp: Slidev’s author-training cost rises with team size; Marp’s stays low. Solo expert → Slidev; many mixed-skill writers → Marp.

Caveats Carried Into S4#

Three personas point at tools with maintenance risk — Spectacle (React team), remark and impress.js (minimalist / spatial). S3 says “fits the need”; S4 must gate these on viability before a long-horizon recommendation.

S4-Strategic: Long-Term Viability#

Reading time: 40-50 minutes

Which tools are safe 3–5 year bets — community health, backing, momentum, lock-in, and the strategic dependencies that decide longevity. Facts as of May 2026.

Table of Contents#

1. Risk-Tier Summary
2. Tool-by-Tool Viability
3. Strategic Synthesis
4. Three “Do Not Start New Projects On These” Flags

Risk-Tier Summary#

Star counts are approximate and drift; treat as order-of-magnitude. reveal.js’s exact current count wasn’t cleanly captured — confirm on the repo (tens of thousands, very high).

Tool-by-Tool Viability#

Quarto — LOW risk (strongest institutional backing)#

• Backing: Posit PBC (formerly RStudio) — a commercial, well-funded company with a long OSS track record. Lowest bus-factor in the set (dedicated team).
• Momentum: Actively growing and investing forward. April 2026: Posit announced Quarto 2 — a ground-up Rust rewrite (new Markdown parser, faster debugging, built-in collaborative editor), due late-2026, engineered backward-compatible with Quarto 1.
• Lock-in: Low–moderate — .qmd is Pandoc Markdown + code cells, close to portable; you’d lose the execution/multi-format pipeline if you left.
• Dependencies: Built on Pandoc (very stable) and renders slides to reveal.js — inherits two durable substrates (and reveal’s single-maintainer caveat for slide output).
• Caveat: heaviest tool; overkill if you only want slides. Not primarily a slide tool — presentations are one output among many.

Slidev — LOW risk (best-funded JS toolchain, highest lock-in)#

• Health: ~46.9k stars; releases roughly weekly (52.x rolling scheme). Continuous feature flow.
• Backing: Part of Anthony Fu (antfu)’s ecosystem; antfu is now affiliated with VoidZero (Evan You’s company, home of Vite/Rolldown/Oxc). Bus-factor: moderate — strongly identified with antfu but embedded in a large, well-funded ecosystem with co-maintainers.
• Strategic dependency (favorable): built on Vite + Vue. Vite 8 (March 2026) is Rolldown- powered (Rust, 10–30× faster), the whole stack consolidated under VoidZero, antfu inside that orbit. Slidev rides the best-funded, fastest-moving JS build toolchain. Risk: tightly coupled to Vue specifically (not framework-agnostic).
• Lock-in: Highest of the Markdown tools — slides are laced with Vue components, v-click, UnoCSS, Vite plugin behavior. Porting out to plain Markdown/reveal.js is non-trivial.
• Caveat: the unconventional 52.x versioning obscures semver signals.

reveal.js — LOW risk (the load-bearing substrate)#

• Health: the canonical HTML presentation framework, very high stars; current major 6.0 (build migrated to Vite), latest patch 6.0.1 (~early 2026). Slow, deliberate cadence — majors years apart.
• Backing: solo-founder model — Hakim El Hattab since 2011, sustained commercially via his Slides.com SaaS (reveal.js is the engine). Bus-factor high in theory, mitigated by 14 years of continuity, a commercial incentive, and a huge contributor pool.
• Lock-in: Low — plain HTML + optional Markdown; content is portable.
• Strategic role: it is itself a substrate — Quarto and many MD→HTML pipelines render to reveal.js. Its stability underwrites other tools; if it faltered, the ripple would reach Quarto’s slide output. That centrality is also why it’s durable.

Marp — LOW risk (best portability, lowest lock-in)#

• Health: multi-repo org; entrance repo ~11.7k stars; all core repos updated within May 2026 (marpit, marp-cli, marp-vscode, marp-core). Consistent, healthy cadence.
• Backing: marp-team community org (lead historically Yuki Hattori). Not solo, not corporate; a coherent multi-repo team. Bus-factor moderate-low.
• Lock-in: Lowest in the set — Marpit is deliberately a skinny CommonMark framework; decks are near-plain Markdown with light directives. Easy to leave.
• Dependencies: self-contained; no heavy framework dependency → low external risk.

impress.js — MEDIUM risk (frozen but durable)#

• Health: ~38.3k stars; last functional release v2.0.0, July 2022. Some 2026 housekeeping (CI/dep bumps) but no feature releases in ~4 years; many open issues.
• Backing: originally bartaz, then henrikingo (to ~2023); now effectively janitorial — no active feature maintainer. Bus-factor high.
• Why MEDIUM not HIGH: it’s frozen and zero-dependency (vanilla CSS3 transforms), so rot risk is low — it will keep working in browsers. But there’s no roadmap and a single niche use case.
• Lock-in: moderate — HTML is portable, but its Prezi-style 3D zoom/rotate effect has no equivalent elsewhere; you’d lose the effect if you migrate.

Spectacle — HIGH risk (acquired parent, stalled releases, JSX lock-in)#

• Health: last release 10.2.3, October 2024 — ~18+ months with no release as of May 2026. ~70 open issues.
• Backing (verified): Formidable Labs was acquired by NearForm (Oct 2023); post-acquisition, Formidable’s OSS portfolio (Spectacle, Victory, urql) has broadly been wound down/handed off. The Oct 2024 work was a React 19 compat fix → maintenance-mode trending to dormant; docs repo already marked deprecated. No active corporate sponsor signal in 2026.
• Lock-in: Very high — decks are React/JSX components with no Markdown exit path; migrating away means rewriting the deck.
• Verdict: usable today, but do not start new long-horizon projects on it.

remark (gnab) — HIGH risk for new adoption (dormant)#

• Health: ~12.8k stars; last push June 2024; the 0.15.0 release effort has lingered for years (issue #602); users repeatedly ask for an up-to-date distribution (#664). No recent releases.
• Backing: solo/community under gnab; effectively unmaintained.
• Name-collision warning: do not confuse with remarkjs/remark, the very-alive Markdown-AST processor in the unified.js ecosystem — different project, same name. All “dormant” findings refer to gnab/remark (the slideshow).
• Mitigant: its content is plain, portable Markdown — the tool’s death doesn’t trap your slides (migrating to Marp/reveal.js is easy). But treat the tool itself as legacy.

Strategic Synthesis#

• reveal.js is the substrate. Quarto renders to it; many pipelines target it. Single-maintainer is a watch-item, offset by Slides.com backing and its role as everyone’s render target.
• Slidev’s Vite/Vue bet aged well. Vite 8 (Rolldown/Oxc, Rust) under VoidZero, with antfu inside — best-funded, fastest JS build stack. Trade-off: deepest authoring lock-in.
• Marp = lowest-risk portable default for plain-Markdown, CI/PDF/PPTX. Quarto = best institutional safety and the only choice for code-executing/multi-format needs. Slidev = best for rich developer demos if you accept lock-in.

Three “Do Not Start New Projects On These” Flags#

All verified:

1. Spectacle — HIGH. No release since Oct 2024; Formidable acquired by NearForm (2023) and OSS wound down; JSX lock-in with no migration path.
2. remark (gnab) — HIGH (new adoption). No commits since ~Jun 2024; long-stalled 0.15.0; dormant. Content is portable, so the tool’s death doesn’t trap your slides.
3. impress.js — MEDIUM. No functional release since v2.0.0 (Jul 2022); only CI/dep housekeeping. Survives because it’s zero-dependency and browser-native — viable only if you specifically want its Prezi-style zoom canvas, with eyes open.

Date Caveat#

reveal.js’s latest-patch date showed a cache inconsistency between sources (Apr 2024 vs npm “~2 months ago”); the more current npm reading (6.0.1, early 2026) was used. Exact reveal.js star count not cleanly captured — confirm on the repo.

Sources#

Slidev releases · antfu · reveal.js · reveal upgrading · marp-team · marp-cli releases · Spectacle releases · impress.js v2.0.0 · gnab/remark #602 · Quarto 2 announcement · Quarto launch · Rolldown 1.0 · VoidZero March 2026

S4-Strategic: Research Approach#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S4 — Strategic (long-term viability) Date: 2026-05-31

Objective#

Answer “WHICH to choose for a 3–5 year horizon?” — assess community health, backing/bus-factor, momentum, breaking-change/migration burden, lock-in, and strategic dependencies.

Dimensions (per tool)#

1. Community health (stars, release cadence/recency, issue responsiveness)
2. Maintainership & backing (solo / community / corporate; bus-factor)
3. Momentum (growing / stable-mature / stagnant / declining)
4. Breaking-change history & migration burden
5. Ecosystem lock-in (how hard to migrate away)
6. Strategic dependencies (Vite/Vue, Pandoc, reveal.js substrate)
7. 3–5 year risk rating

Method#

GitHub release pages, repo activity, maintainer profiles, and corporate-status sources. Explicitly verified the items most likely to change the conclusion:

• Spectacle: confirmed Formidable→NearForm acquisition (Oct 2023) and last release (10.2.3, Oct 2024).
• remark: confirmed gnab/remark dormancy and distinguished it from the unrelated, healthy remarkjs/remark AST processor.
• impress.js: confirmed last functional release (v2.0.0, Jul 2022) vs. 2026 janitorial activity.
• Quarto: confirmed Posit backing and the April 2026 Quarto 2 (Rust) announcement.

Confidence#

• High: maintenance verdicts (release dates, backing) — these are the load-bearing findings and are well-sourced.
• Medium / flagged: exact star counts (drift; reveal.js not cleanly captured); reveal.js latest- patch date (source cache inconsistency, resolved to the more current reading). Flagged in the README.

S4-Strategic: Recommendations#

Topic: 1.110.6 Code & Markdown Presentation Frameworks Phase: S4 — Strategic

Risk Verdicts#

LOW risk (safe 3–5 year bets):

• Quarto — corporate backing (Posit), forward investment (Quarto 2 Rust rewrite). Safest on backing alone. Heavy; choose when you need execution/multi-format.
• Slidev — best-funded JS toolchain (Vite/VoidZero/antfu), fast growth. Accept the highest authoring lock-in.
• reveal.js — the durable substrate; stable API, commercial backing via Slides.com.
• Marp — lowest lock-in, healthy community org, ideal CI/portable default.

MEDIUM risk:

• impress.js — frozen since 2022 but zero-dependency and browser-native, so it keeps working. Use only for its unique Prezi-style zoom, eyes open.

HIGH risk (do not start new long-horizon projects):

• Spectacle — no release since Oct 2024, Formidable wound down post-NearForm acquisition, JSX lock-in with no exit. Usable today, risky tomorrow.
• remark (gnab) — dormant since mid-2024. Mitigant: portable Markdown content isn’t trapped.

The Strategic Picks#

Cross-Survey Strategic Note#

Slidev’s viability is partly Vite’s viability. The Vite 8 + Rolldown + VoidZero consolidation (see 1.114-build-tools, refreshed) is the strongest signal in Slidev’s favor — it sits on the best-funded build stack in JavaScript. Conversely, reveal.js’s role as a substrate means its health matters to Quarto users too. Read 1.114 and this S4 together when betting long-term.

Final Lifecycle Recommendation for the Survey#

• Default published recommendation: Slidev (dev talks), Marp (docs/CI/portable), reveal.js (control/longevity), Quarto (reproducible) — all LOW risk.
• Caveat prominently: Spectacle (HIGH), remark (HIGH), impress.js (MEDIUM/niche).
• This completes S1–S4 + DOMAIN_EXPLAINER; topic is ready for validation and, if desired, Hugo conversion and publication to the frontend cluster.