Spectacle: React Presentation Slides Built From JSX

The problem Spectacle solves for React developers

A conference talk usually splits into two artifacts: a slide deck made in a presentation app, and a code editor open beside it for the live demo. Keeping the two in sync is manual work. The slide that says "here is the reducer" and the editor tab showing that reducer drift apart the moment you refactor. Spectacle's answer is to make the deck itself a React application. Slides are components, layout is JSX, and the code you show on screen is the same code the build already knows about. The README describes it as "A ReactJS based Presentation Library" and the package description adds that it gives you "the ability to live demo your code." The audience is narrow and specific: front-end engineers who already have a React toolchain, who are comfortable writing markup by hand, and who would rather commit a deck to git than export a PDF. If you have never set up a bundler, this is not the tool that will teach you.

How a Spectacle deck is structured

The repository is a pnpm monorepo. The root package.json is named spectacle-monorepo and holds only devDependencies (Babel presets, webpack, Jest, Puppeteer, TypeScript, wireit, and the changesets CLI), so the published library lives under packages/ rather than at the root. The top-level tree lists packages/, docs/, examples/, website/ and a pnpm-workspace.yaml, which is the standard shape for a project that ships one core package plus documentation and sample apps. The examples are split by authoring style: examples/js, examples/md, examples/mdx, examples/one-page and examples/typescript. That split is the clearest signal of how the library is meant to be used. You can write slides as plain JSX components, or feed Markdown or MDX through the library, and the one-page example suggests a single-file deck is a supported shape. The root devDependencies include babel-plugin-transform-jsx-to-htm, which points at an htm-based rendering path for the Markdown or MDX variants rather than a full React element tree. The docs site source sits in the docs folder of the repository, and the README points there for anything beyond getting started.

Installing Spectacle and building a first deck

The README's Getting Started section is a pointer to the docs site rather than a step list. The root package.json does show the repository's own script names, including start:js, which runs a watch build through nps and wireit, and the version script, which runs pnpm changeset version followed by pnpm install --no-frozen-lockfile. Those belong to the monorepo's development workflow, not to a consumer project, but they are the only concrete commands the repository files provide.

pnpm changeset version
pnpm install --no-frozen-lockfile

For your own deck, the repository layout is the guide: examples/js, examples/md, examples/mdx, examples/one-page and examples/typescript each hold a runnable setup, and the docs folder holds the documentation source the README links to. Pick the example whose authoring style matches your talk, copy its structure, and run it with whatever bundler the rest of your project already uses. The monorepo's own build is wired through package-scripts.js and wireit rather than plain npm scripts, so the exact commands a consumer runs depend on your own toolchain. What you should see when it runs is a full-viewport slide with keyboard navigation, which is the default presentation behaviour rather than something you wire up yourself.

Where Spectacle stops being the right tool

The cost of writing slides in JSX is that nobody who does not write JSX can edit them. A marketing colleague cannot fix a typo, a designer cannot nudge a margin, and a speaker who is not on the engineering team cannot rehearse a change without a pull request. The Markdown and MDX examples soften this, since content moves out of component code, but the deck still has to be built and served by a toolchain. Two more limits are worth naming. First, the README does not document PDF export, a presenter view, or speaker notes in the root file; the docs site is where that would live, and if your venue requires a PDF handout, confirm the capability before you commit to the format. Second, the repository's last push was on 2026-04-12, and the most recent release listed is [email protected] from 2025-10-10. The README carries a maintenance badge reading "Active" and a Maintenance Status section stating that Formidable is actively working on the project, but the release history is the number to check against your own tolerance for dependency churn. A deck you present once a year can tolerate a slower cadence than a template your whole team forks.

Spectacle against reveal.js and Slidev

The obvious comparison is reveal.js, which is HTML and CSS first: you write markup or Markdown, load a script, and get a deck in the browser with no build step. Spectacle's difference is that it does not have a runtime you drop into a page; it is a component library you compile. That buys you typed props in the TypeScript example, real imports in your code samples, and the ability to render a live component inside a slide rather than a screenshot of one. It costs you the zero-config path: reveal.js works from a single HTML file, Spectacle needs React, a bundler and a build. Slidev sits closer to Spectacle in spirit, since it also targets developers and supports code in slides, but it is a Vue-based tool with its own Markdown-centric authoring model. Choosing between them is mostly choosing your framework. If your team writes Vue, Spectacle's React dependency is a hard stop; if your team already ships React, the JSX model means the deck reuses the same mental model, the same linting and the same component patterns as the product.

Licence, upgrades and what maintenance costs you

Spectacle is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the permissive end of the spectrum and imposes no copyleft obligation on your deck, but it is not legal advice; if you are redistributing the library inside a product, have your own counsel read the LICENSE file at the repository root. On upgrades, the monorepo uses changesets, with a version script that runs pnpm changeset version followed by pnpm install --no-frozen-lockfile. That tells you releases are cut from changeset entries, which is a good sign for changelog quality when you need to read what broke. Practically, the upgrade surface for a consumer is the component API rather than the build: your deck imports from the package, so a breaking change in those exports is what forces you to edit files. The repository also pins pnpm neverBuiltDependencies for puppeteer, a detail that matters only if you are working inside the monorepo rather than consuming the package.

Editorial conclusion

Adopt Spectacle if your talk is already a React project and you want slides, code samples and live demos in one language; skip it if you need a non-developer to edit decks, since every change is a code change. Before committing, verify the current package version on npm, read the docs folder in the repository for the component API, and check the examples directory for the JS, MD, MDX, one-page and TypeScript setups to see which one matches your build. The repository's last push was on 2026-04-12, so treat the release cadence as something you confirm yourself rather than assume.

Frequently asked questions

Official sources

1. FormidableLabs/spectacle on GitHub
2. License: MIT
3. Project website
4. README
5. Releases