Write Your Slides in Text You Can Diff

I recently needed to build a talk — a real slide deck, not a scratch outline — and instead of opening presentation software and pushing text boxes around, I generated the whole thing from a text source and a small build script. The deck came out of running a command. That choice sounds fussy until you’ve lived the alternative: a binary file you can’t diff, styling that drifts every time you touch it, and no way to reproduce or review what changed. Slides are content, and content belongs in a form you can version, not trapped in a blob.

A binary deck is a black box to every tool you trust

The core problem with a hand-built deck is that it’s opaque to your normal workflow. You can’t meaningfully diff two versions — “what changed between the draft and the final?” has no good answer when the file is binary. You can’t review it the way you’d review a change to anything else. You can’t rebuild it from a source, because it is the source, and the source is a pile of positioned shapes. Every edit is manual, and manual edits don’t leave a history you can read.

If you can’t diff it, you can’t review it, and if you can’t review it, you’re just hoping the last change didn’t break anything.

Text sources fix all of that at a stroke. Whether it’s Markdown-driven slides (tools like Marp turn plain Markdown into a deck) or a script that assembles slides programmatically, the input is text. Text diffs. Text lives in version control. Text gets reviewed. The deck becomes a build artifact of something you can actually inspect.

One source of truth for how it looks

The payoff I felt most was styling. In a hand-built deck, the look lives in every slide at once — change the accent color and you’re hunting through forty slides updating it by hand, missing three, and shipping an inconsistent deck. In a slides-as-code setup, the theme is defined once: colors, fonts, spacing, the footer, the logo placement, all in a single place the whole deck reads from. Change it there and every slide updates. Nothing drifts, because nothing is styled by hand.

That single-source-of-truth property is the same reason we centralize design tokens or config anywhere: define the shared thing once and reference it, so consistency is automatic instead of a chore you fail at slide by slide.

Content and presentation, finally separated

Building slides from text also splits the two jobs that hand-editing tangles together. When you write in a text source, you’re writing content — the actual points, in order. The build turns that into the presentation — the layout, the theme, the formatting. You stop fiddling with where a box sits and focus on what the slide says, because the styling is the build’s job, not yours. That separation is why a text-sourced deck stays consistent and a hand-built one slowly becomes a patchwork: in the hand-built one, every slide is a fresh chance to reinvent the layout.

It’s the same reason a build step beats manual assembly for anything repeated: the machine applies the rules the same way every time, and humans don’t.

Reproducible, reviewable, regenerable

Once the deck is a build, it inherits the properties of every other build:

• Reproducible. Run the command, get the deck. Same input, same output, every time — no “which version of the file is the real one” archaeology.
• Reviewable. A change to a slide is a change to text, so it can be read, commented on, and approved like any other change.
• Regenerable. Update the content or the theme and rebuild. Repeated decks — a talk you give quarterly, a template your team reuses — become trivial to keep current instead of a copy-paste ritual that quietly rots.

That “easy to keep current” point is the quiet one that matters most over time: when regenerating is one command, the deck stays honest, the same way that docs go stale exactly when publishing them is hard. Friction is what kills upkeep, and a build removes the friction.

Know when the trade isn’t worth it

I’ll be honest about the cost, because slides-as-code isn’t free and isn’t always right. There’s real upfront setup — the theme, the build, learning the tool — that a quick three-slide throwaway doesn’t justify; sometimes the presentation software is the right call. And it’s a worse fit for highly visual, freeform, design-led decks where precise manual placement is the whole point. The sweet spot is content-driven decks: technical talks, anything template-consistent, anything you’ll regenerate or maintain. For those, treating slides as code — text source, one theme, a build you can rerun — turns a deck from a fragile artifact into something you version and trust, the same way I think about documentation as infrastructure. If you’ve built decks from a text source and have a tool or workflow you like, I’d love to hear about it.