1. Installing Slidev, and the 554 MB Download That Waits Until Your First Export

By the end of this part you will have Slidev 53.0.0 installed, a deck of your own written in one Markdown file, a live preview that redraws in a median of about 175 milliseconds after you save, and a PDF on disk. You will also know the two downloads that make up most of the cost, because the starter installs the first one and leaves the second for your first export to discover.

Here is the whole bill, measured on our machine: 59 seconds and 533 MB for the project, then 5 minutes 29 seconds and 554 MB for the browser that exports it. The editing loop is quick. Getting to your first PDF is not.

Why Slidev, and why a whole course on it

Slidev turns a Markdown file into a slide deck that runs in the browser. You write slides.md, separate slides with three dashes, and get code highlighting, layouts, presenter notes, and exports to PDF, PNG, PowerPoint or a static website. It is aimed at developers, and the --- separator is the entire learning curve for the first hour.

We picked it for a four part course the same way we pick every repo course: by checking it will still be alive when someone finds this next year. We pulled the numbers from the GitHub API on 24 September 2026 and compared it against the other Markdown and docs tools we considered.

Repo	Stars	Last push	License	Top author in last 100 commits
slidevjs/slidev	48,830	2026-09-16	MIT	28 of 100
d2lang/d2	25,498	2026-09-20	MPL-2.0	100 of 100
jackyzha0/quartz	13,281	2026-09-20	MIT	94 of 100
marp-team/marp-cli	3,831	2026-09-08	MIT	not checked

The last column is the one we care about most. D2 and Quartz are good projects, but nearly every recent commit comes from one person, which is a bus factor of one. Slidev's lead maintainer, Anthony Fu, wrote 28 of the last 100 commits, a release bot wrote 16, and the remaining 56 came from a spread of other contributors. Version 53.0.0 shipped on 16 September 2026, eight days before we installed it. We will come back to Marp in Part 4, where we run the same deck through both.

Prerequisites, and how long this really takes

• Node.js 22.12 or newer. The @slidev/cli package declares "node": ">=22.12.0". We used 22.22.0. We also tried 20.20.2, which we cover under what broke.
• About 1.1 GB of free disk if you want PDF export: 533 MB of node_modules per project plus 554 MB of Chromium in a shared cache.
• A terminal and a browser. No account, no API key, nothing to sign up for.
• Time: about 7 minutes of mostly waiting on a home connection, of which 5 and a half are the Chromium download. The writing part takes as long as your talk takes.

Our test machine: an Apple M4 Pro on macOS 26.5.1 with npm 10.9.4. Every timing in this part comes from that machine on a cold npm cache unless we say otherwise, and your network will move the install numbers more than your CPU will.

Step 1: scaffold the project

The official starter is one command:

npm init slidev@latest my-talk

It took 2.85 seconds, wrote the project, and then asked a question:

  Scaffolding project in my-talk ...
  Done.

? Install and start it now using npm? (Y/n)

Answer yes in a normal terminal and it installs and opens the browser for you. We ran it the way a script or an editor task would, with no keyboard attached, and the prompt simply ended. Exit, no error, no node_modules. If you ever wrap this in automation, that silence is the thing to watch for. The folder it leaves behind is fine, you just have to install it yourself:

cd my-talk
npm install

That install took 59.0 seconds with an empty npm cache and produced a 533 MB node_modules with 435 top-level packages. The two biggest single items are Mermaid at 127 MB and the Monaco editor at 100 MB, which is what powers the live code editor you can drop into a slide. A second project on a warm cache took 41.5 seconds and came out the same 533 MB, so you pay the disk cost per deck, not once.

Step 2: open the live preview

npm run dev

That script is slidev --open. The terminal printed the server banner and the local HTML answered in 2.15 seconds. That number flatters it, because the HTML page is a shell and the slides render in JavaScript afterwards. So we measured from inside a real headless Chromium: open the URL, wait until the first slide's heading exists on the page. Across two runs that took 2.3 and 5.6 seconds. We did not pin down why the second run was slower, so treat "a few seconds" as the honest answer.

The banner lists the addresses worth bookmarking:

  public slide show   > http://localhost:3030/
  presenter mode      > http://localhost:3030/presenter/
  slides overview     > http://localhost:3030/overview/
  export slides       > http://localhost:3030/export/

Presenter mode is the one you will use on the day: current slide, next slide, your notes and a timer, on a second window while the audience sees the first.

Then we timed the editing loop, which is what you will actually live in. A script changed the title on slide 1 and waited for the new text to appear in the browser, ten times across two server sessions. The results were 52, 87, 145, 146, 169, 180, 196, 221, 332 and 366 milliseconds. Call it a median of about 175 ms. In practice that means the slide has changed by the time your eyes move from the editor to the browser.

Step 3: write your own deck

The starter slides.md is 662 lines of feature tour. It is worth one scroll, then replace it. Here is a complete four slide deck you can paste over it. It is a tiny talk about this install:

---
theme: default
title: What Slidev cost us to install
layout: cover
---

# What Slidev cost us to install

Measured on one laptop, 24 September 2026

---

# The bill

- Project install: 59 seconds, 533 MB
- Chromium for export: 5 minutes 29 seconds, 554 MB
- First PDF: 12.96 seconds

<!-- Say the Chromium number slowly, it is the point of the talk -->

---
layout: two-cols
---

# Editing

Hot reload median about 175 ms

::right::

# Exporting

One Chromium download, shared by every project

---
layout: end
---

That exact file exported to a 4 page PDF in 5.36 seconds for us, cover, bullet list, two columns and the black end slide. It uses our real install numbers, so it doubles as a record of this part.

Three pieces of syntax carry almost everything:

• The block at the very top is headmatter. It is YAML, it configures the whole deck (theme, title) and also the first slide (layout: cover).
• --- on its own line starts a new slide. If a --- block is followed by YAML and another ---, that YAML is frontmatter for the next slide only, which is how the two-cols and end layouts are set.
• The last HTML comment on a slide becomes its presenter note. The word "last" matters. We tested it and the details are below.

There are 21 built-in layouts in 53.0.0, including cover, center, two-cols, two-cols-header, image-right, quote, fact and section. We got that list by misspelling one on purpose, which is the fastest way to see them.

Step 4: export a PDF, and the second download

npm run export

On a fresh project this fails in about one second:

Error: The exporting for Slidev is powered by Playwright,
please install it via `npm i -D playwright-chromium`

The error is honest, and the exporting page of the docs says the same thing. What neither the error nor the docs mention is the size of what comes next:

npm i -D playwright-chromium

That command took 5 minutes 29 seconds for us. The npm package is small. The time goes on its install step, which downloaded a full Chromium build (359 MB) and a separate headless shell (195 MB) into ~/Library/Caches/ms-playwright/. That cache is shared, so the next project that needs the same Playwright version skips the download.

After that, the export works:

npm run export

The 16 slide starter deck exported in 12.96 seconds to a 6.65 MB slides-export.pdf, 16 pages at 735 by 414 points. We rendered the pages back to images and checked them by eye: headings, emoji, code blocks and the cover image all came through.

What broke

A bare install cannot find its own default theme. The docs let you skip the starter and install only the CLI. We did, in a clean folder:

npm init -y
npm i -D @slidev/cli

Then we ran an export with no keyboard attached and got The theme "@slidev/theme-default" was not found and cannot prompt for installation, exit code 1. In a normal terminal the same situation asks whether to install the theme. The theme is a separate package and the CLI does not pull it in for you. Fix it by installing it alongside the CLI:

npm i -D @slidev/cli @slidev/theme-default

We think exit 1 is the right behaviour here. A CI job that fails loudly is better than one that hangs on an invisible prompt.

A console error on every export. Each export printed [console.error] Failed to patch FloatingVue TypeError: Cannot read properties of undefined (reading 'Popper') from the Twoslash code tooltip integration. Every export still completed and the PDFs looked right, so we treat it as noise. We note it so you do not spend time chasing it.

A YAML error points at the wrong line. We put an unquoted colon in the title, title: Broken: yaml: here. The build stopped with YAMLParseError: Nested mappings are not allowed in compact mappings at line 1, column 8, exit 1. The title was on line 2 of the file. The parser counts from inside the headmatter block, not from the top of slides.md, so on a slide further down, "line 1" can be hundreds of lines into your file. Quote any value with a colon in it:

title: "Broken: yaml: here"

Our own mistake with a script. Our first attempt at timing hot reload edited the first line starting with #, which in the starter deck is a YAML comment in the headmatter, not a heading. Nothing on screen changed and the script timed out after 30 seconds. The tool was fine. It is a useful reminder that # means two different things in the same file.

Common mistakes

• Using --- as a horizontal rule. In normal Markdown it draws a line. In Slidev it starts a new slide. We wrote a paragraph, a ---, and another paragraph, and got two slides. A --- inside a fenced code block is safe: we checked, and it rendered as code.
• Misspelling a layout. layout: tow-cols printed a warning listing the 21 real layouts, then built and exported anyway with exit code 0. The slide quietly fell back to the default layout. Read the terminal, because your CI will not.
• Putting the note before the content. A comment at the top of a slide, followed by content, did not become a presenter note. Only the last comment block does. The syntax guide says exactly this, with an example, and our test agreed with it.
• Trusting an old Node. On Node 20.20.2 the install printed 10 EBADENGINE warnings. Build and export still exited 0 on our small deck. That is luck, not support. We did not test the dev server on 20, and neither should you in front of an audience.
• Answering nothing to the scaffold prompt. If npm init slidev ends without installing, it is not broken. Run npm install yourself.

What we did not test

We did not test Windows or Linux, pnpm or Bun installs, or any machine without an internet connection. Our install timings are one home connection on one day. The hot reload numbers are for editing a single heading in a 16 slide deck; a deck with heavy Mermaid diagrams or dozens of code blocks will be slower, and we have not measured by how much. We have not used Slidev in front of a live audience for this part, only in a browser and in exports.

The escape hatch

Nothing here is locked in. Your deck is one plain Markdown file that any editor can open. To remove everything we installed:

rm -rf my-talk
rm -rf ~/Library/Caches/ms-playwright/chromium-1243 ~/Library/Caches/ms-playwright/chromium_headless_shell-1243

Check the folder names first with ls ~/Library/Caches/ms-playwright/: the numbers change with each Playwright release, and other tools on your machine may be using older builds in the same folder. We had two older builds from February in there that we left alone.

Next

You have a working deck and a PDF. In Part 2 we build a real talk, not the starter tour: code that highlights line by line as you click, a diagram, speaker notes, and what each of those costs at export time.