reveal.js vs slidev: hand-written HTML slides against Markdown decks for developers

The authoring unit: HTML markup against a Markdown file

A reveal.js deck is an HTML document. Slides are section elements, vertical stacks come from nested sections, and the framework is driven through a JavaScript API with configuration options and an extensive event system. The README lists nested slides, Markdown support, Auto-Animate, PDF export, speaker notes, LaTeX typesetting, syntax highlighted code and an extensive API. You write the DOM yourself, which is the point for a developer who wants precise layout control, and the cost is that the file is HTML with all the ceremony that implies.

A slidev deck is a Markdown file. On top of it the tool adds code highlighting, live coding, Mermaid diagrams, KaTeX, icons, an integrated editor and a VSCode extension. Because it is Vue 3 under the hood, a slide can embed a Vue component, and because it runs on Vite you can add Vite plugins and npm packages. npm init slidev scaffolds the whole project.

The practical difference is that reveal.js does not interpret your content beyond the DOM you hand it, so you can write any HTML you like. slidev compiles Markdown, which raises the ceiling and tightens the contract: the file has to fit the shape slidev expects.

What has to be running when you present

reveal.js decks are files. Once you have the HTML, the framework's JavaScript and whatever plugins you use, the deck opens in a browser. There is no backend, no package manager and no build step in the middle of presenting, and a nested-slide deck behaves the same on a laptop with no network as on a conference machine with one.

slidev's authoring loop needs Node.js 20.12.0 or newer and a running dev server, because the Markdown is compiled by Vite and hot-reloaded as you type. Presenting from that machine is fine. Presenting with the presenter mode on another window, or on your phone, means the deck has to be reachable from that second device, which is a different question from copying a folder onto a USB stick.

Both are MIT licensed, so this is not a licensing decision. It is an ownership question: for reveal.js the toolchain belongs to whoever opens the file, for slidev it belongs to whoever runs npm install.

Animation: matched DOM moves against live components

reveal.js ships Auto-Animate, which animates between two states of the same elements when consecutive slides share matching attributes. You get object movement across slides without writing keyframes. Everything else is the documented API and a plugin system, and plugins can add behaviour that the framework's own changes later break.

slidev has no equivalent concept, because it does not need one. A slide is a Vue component, so transitions and interactivity are ordinary frontend code with access to the component lifecycle, the router and any npm package. That is more power and more ways to get stuck.

The fair comparison is between a declarative shortcut and the general tool. Auto-Animate suits slides whose transitions are consistent and mechanical. If a slide needs live data, or state that has to persist across the whole deck, slidev's model fits better, because there the slide is just a component that can hold state.

Presenter view, drawing and recording

reveal.js ships speaker notes and a speaker view, the second window that shows the current slide, the next slide and the notes to the person presenting. That is the classic arrangement, and it has carried most conference talks for a decade.

slidev goes further in ways that matter on stage. Its presenter mode runs in another window, or on your phone, to control the slides. Drawing and annotation on top of a slide come from Drauu. Recording and a camera view come from RecordRTC. The feature list also includes the integrated editor and the VSCode extension, so the same person can write and rehearse without leaving the tool.

If your talk needs to mark up a live diagram, or you want a recording of the session, reveal.js leaves that to plugins you would have to find and wire up yourself. slidev has it in the box, and that is the single clearest functional gap between the two.

Export: one PDF against PDF, PNG and PPTX

reveal.js documents a PDF export. The framework is a browser framework, so printing to PDF preserves the layout as the browser renders it, and the feature list pairs that export with LaTeX typesetting and syntax highlighted code. The deck you show and the PDF you send are the same document seen two ways.

slidev exports to PDF, PNG and PPTX, a wider set of destinations, and its themes are npm packages a team can share, which is part of why the tool has an audience. The catch sits in our analysis of slidev: presenter mode, drawing, recording and embedded Vue behaviour have no representation in any of those exports. What you hand over is a picture of the deck rather than the deck.

That distinction matters for corporate work. If the artefact is a file other people receive, a reveal.js PDF matches what the audience saw, because it is a print of the same page. If the artefact is a set of slides you will present yourself, the interactive formats are a liability rather than an asset.

Where each one falls short

reveal.js's weakness is the audience for the skill, not the tool. Writing slides means writing HTML and CSS, and the project contains no graphical editor of its own; the README points people who want one to slides.com, a separate paid service from the same people. Our analysis of reveal.js says to skip it if you need a graphical editor or rapid visual design. Version 6.0 landed in March 2026 and broke things relative to 5.x, so plugins and custom themes need checking against the 6.0 release notes before you depend on them.

slidev's weakness is export fidelity and version churn. Everything interactive is lost on export. The version also moves in ways that are easy to miss: our analysis of slidev records that v52.20.0, v52.20.1 and the major v53.0.0 were all published on 2026-09-16 within about four hours of each other, so a floating dependency can cross a major boundary while nobody is looking. The same version has to be written into three package.json files at once, at the root, in packages and in docs, kept aligned by one bumpp invocation rather than by hand.

MIT for both, and the choice by scenario

Both projects are MIT licensed, so neither carries a copyleft obligation or a source-available restriction, and either can be modified and hosted without publishing anything. reveal.js's last push was on 2026-09-30 and slidev's on 2026-10-02, so both are being worked on.

The choice then comes down to who authors the deck. If it is a developer or a technical writer who wants the deck under version control and the layout under their own control, reveal.js is the answer, and the browser-only delivery is a bonus. If it is a developer audience with code in the deck, who wants to type Markdown instead of HTML, and who wants live coding, Mermaid and npm themes, slidev is the answer.

A mixed team is where this gets awkward. reveal.js asks a non-programmer to edit HTML; slidev asks them to install Node. If several people will edit the slides, look at slidev's integrated editor and VSCode extension first. If they will install nothing at all, the graphical editor at slides.com is the honest answer, and a reveal.js deck edited by one person is the second.

Bottom line

Choose reveal.js for a deck you will hand over as files or as a browser-printed PDF, and slidev for a deck you will present yourself with code in it. Verify the version you pin before you publish: the reveal.js 6.0 release notes against your plugins, and the slidev version in all three package.json files.

Sources

1. hakimel/reveal.js repository
2. hakimel/reveal.js README
3. slidevjs/slidev repository
4. slidevjs/slidev README