2026-09-14 · Markdown workflows

Deckstream 2026: Markdown to Slidev, Live-Rendered

On September 12, 2026, a user named aspic posted Deckstream – write Markdown, get live-rendered Slidev presentations to Hacker News as objectID 49672433. One point at the time of writing, no comments, a single self-replying link to deckstream.org. That is a quiet launch by Hacker News standards. The product is also doing something the Markdown tool ecosystem has been circling for two years without quite landing: a real browser slide editor that updates as you type, with Slidev doing the actual rendering underneath.

The headline on the site is the line Presentations, at the speed of thought. Underneath that, three feature cards do the work of explaining what the product actually does: See it as you type (a CodeMirror editor on the left, an embedded Slidev iframe on the right, both panes live), Markdown in, slides out (the deck is structured as a document, with headings, dividers, and lists, not as a drag-and-drop canvas), and Publish to a link, not a file (one click builds a static shareable URL). A fourth card adds the toggle that makes the editor honest: Slides or plain text — your call, which lets you flip between a WYSIWYG slide view and the raw Markdown view of the same deck. The whole product is, in effect, a Markdown live-preview window bolted onto a hosted Slidev renderer, with publish and unpublish as the only output controls that matter.

What the JavaScript bundle tells you about the product

The interesting confirmation is in the production JavaScript at deckstream.org/assets/index-BLnIVnLd.js, which is a 1.98 MB minified bundle. Inside it you can see the actual architecture, not just the marketing copy. The editor is CodeMirror — five matches for codemirror in the bundle, plus a reference to a Monaco-style plugin that is loaded but not the primary surface. The slide preview is an iframe whose source is built with a template literal: ${a}?embedded=true, where a is the Slidev deployment URL for the current deck. The Slidev navigation messages — {target: "slidev", type: "navigate", no: e+1} — are posted between the editor window and the iframe via postMessage, which is how the cursor position drives slide number without the editor having to reimplement Slidev's own navigation.

The persistence and sharing layer is a small REST surface, also visible in the bundle: GET /api/decks/${id}/preview for a static read-only build, PUT /api/decks/${id} for autosave, POST /api/decks/${id}/publish for the share link, and POST /api/decks/${id}/unpublish to take a deck back to private. Each deck object carries a publishedUrl field and a publishedAt timestamp; the dashboard surfaces a Recently published section and a yellow badge that reads Unpublished changes when the saved version drifts from the live one. Authentication is WebAuthn passkeys, with explicit getLoginChallenge and getTokenWithPasskey helpers next to a standard Auth0 SPA integration. There is no password field anywhere on the site, and the home-page line Sign in to open your decks — nothing to install, nothing to configure is the entire pitch.

Themes are also pluggable. The deck settings object accepts a theme field, and the themes object maps plan names to allowed theme keys: {free: ["deckstream"], pro: ["deckstream"]}. At launch both plans include the same default theme; the surface area is there for paid themes later. The accent color picker accepts a hex value matching #([0-9a-f]{3}|[0-9a-f]{6}), and the date field uses the European format dd.mm.yyyy. None of this is shipping novelty — it is a presentation tool that picked sane defaults and then stopped.

Where Deckstream sits in the Markdown writer's pipeline

The cleanest way to think about Deckstream is as one more pipeline position for someone whose canonical artifact is a Markdown file. Across the past months the Markdown tools that have shown up in the editor pipeline here — Markdown-as-agent-memory, Marginal as the agent-config authoring surface, OzBrain as the cross-agent brain, MDedit as the privacy-first cross-platform editor, the headless block frameworks — have all been at the source end or the editing end of the writer's loop. Deckstream is the first one in a while at the presentation output end: it does not write the canonical document for you, and it does not publish it back as a long-form post. It takes a document and turns it into something you can stand in front of a room and click through.

That distinction is the one that justifies treating Deckstream as a complement to md2rich rather than a competitor. md2rich converts Markdown into rich text for paste-into-LinkedIn, X Articles, Medium, Notion, or Substack — destinations where the reader scrolls and the writer's job is to make the paragraph look right in a feed. Deckstream converts Markdown into slides for a room or a recorded talk — destinations where the reader watches and the writer's job is to make a sequence of one-idea-at-a-time screens. Both keep Markdown as the canonical artifact. Neither needs the other, and they do not overlap in what they actually output. The simplest way to put it: md2rich is the rich-text paste end, Deckstream is the slide-deck end, and a Markdown file is the only thing both of them need.

Both also share a property that has become more valuable than the feature lists suggest: the document never leaves the browser. md2rich is a static client-side converter — open the page, paste Markdown, copy rich text, close the tab; the server is never involved. Deckstream's preview pane is a Slidev iframe, the persistence is a small REST API, and the share-link build is a static export, but the editor itself runs in the page. For a presentation that contains unreleased product details, internal architecture, or customer context, that is the property that matters more than the Slidev integration underneath.

A worked example: the same Markdown, three destinations

The simplest demonstration is to take one Markdown source and walk it through the three places a writer might want it to land. Start with a short outline as you would write it in any editor:

---
theme: deckstream
title: Q3 platform review
date: 14.09.2026
accent: '#2e62ea'
---

# Q3 platform review

# Why we changed the API layer

Three lines of context, one decision, one consequence.

- REST shipped January, hit a tooling ceiling by May
- GraphQL tried April, added a schema tax nobody wanted to own
- tRPC shipped August, removed the schema step entirely

# What changed for customers

- One typed client, no schema drift
- Streaming default for long-running jobs
- Internal teams write procedures, not resolvers

# What is still on the list

- Migration of legacy REST endpoints, currently 41 percent done
- Per-tenant rate limits, expected by end of September
- Internal SDK that matches the public surface

That file is the canonical artifact. Three things happen to it depending on where you want it to land.

As a slide deck in Deckstream: paste the Markdown into the left pane and the right pane renders it as a Slidev deck on every keystroke. Each --- divider becomes a slide break, each # heading becomes a slide title, and the bullet lists inherit the theme's typography. The toggle to Slides or plain text — your call lets you flip into the Markdown view when you want to restructure without losing the visual reference. One click on Publish to a link, not a file returns a URL that any browser can open, and the link stays live until you click unpublish. The published version is static, which means it loads fast, it survives the company laptop being lost, and it does not require the recipient to sign in.

As a LinkedIn or X Articles post: this is where md2rich lives. Open md2rich, paste the same Markdown, copy the rich-text output, and paste it into the LinkedIn composer or the X Articles editor. The bullet lists land as actual bullets, the headings become real headings (LinkedIn does not render # as styled text, so the conversion matters), and the three short paragraphs survive intact. The deck's --- dividers do not — they are a Slidev artifact, not a Markdown feature — so you would write a LinkedIn post that does not include them. The same canonical file is the starting point, with two or three lines removed for the destination.

As an internal Confluence or Notion page: most internal documentation tools now accept pasted Markdown reasonably well, and the same source file pastes into them without the rich-text conversion step. Where md2rich earns its keep is when the destination is one of the few remaining holdouts that strips structure on paste: the LinkedIn composer, the X Articles editor, the Substack post editor, the Medium draft view. For those four destinations, you need a converter that knows what each one accepts.

The point is not that Deckstream and md2rich are interchangeable. They are not. The point is that the Markdown file is the same in both cases, and that a writer who treats Markdown as the canonical artifact can route the same source to either destination without rewriting.

What Deckstream is not

It is worth being explicit about the gaps, because the home-page copy is tight enough that it is easy to over-read. Deckstream is not a real-time collaboration tool. There is one editor and one published URL, with the Unpublished changes badge telling you that the saved version and the live version are not the same; there is no live cursor, no comment thread, no presence indicator. It is not a slide-template marketplace. There is one theme at launch on both plans; the architecture has room for more, but they are not shipping. It is not a desktop application. The site is a single-page React app; there is no Electron build, no .dmg, no VS Code extension. It is also not a serious competitor to PowerPoint or Keynote for design-driven decks — the entire product thesis is that for technical presentations, the deck is the document, and you do not want to drag boxes around to write it.

What it is, in one sentence: a hosted Markdown editor whose preview pane is a Slidev iframe, with one-click publish to a static share link and no installer in the way. The Hacker News launch was quiet because the product is small and the audience is specific — people who would rather write a presentation as a document than design it as a deck. That audience is real and has been waiting.

For comparison, this is what a Deckstream deck's frontmatter looks like, lifted from the documented format:

---
theme: deckstream
title: My presentation
date: today           # or dd.mm.yyyy
info: |
  ## Markdown + Slidev, in the browser
  One-line summary that appears on the cover slide.
---

The theme, title, date, and info fields are exactly what a Slidev deck would parse; Deckstream accepts them as-is and forwards them through to the embedded renderer. That is the whole reason the preview pane can be a real Slidev iframe rather than a reimplementation: there is nothing to translate. If you already write Slidev decks in Markdown locally, the only thing Deckstream changes is where you point your browser.

Bottom line

Deckstream is a useful addition to the Markdown writer's toolkit precisely because it does not try to be one. It takes a Markdown file, renders it as a Slidev deck in the browser, lets you publish it as a static link, and stays out of the way. The September 12, 2026 launch on Hacker News was quiet but the product itself is doing real work. If you write technical presentations and have been hand-converting Markdown to Slidev by running a local Slidev dev server, the in-browser version is the workflow most people were waiting for. If you write technical posts and have been converting Markdown to rich text by hand, md2rich is the same idea at the other end of the pipeline. The two together cover the two most common destinations for technical prose written in Markdown, and neither one sends the document to a server to do it.

The wider pattern is that Markdown is becoming the canonical intermediate format for more surfaces than it was designed for: agent memory, agent configuration, slide decks, rich-text posts, knowledge bases, headless editor frameworks. Each new surface adds a converter at one end and a renderer at the other. Deckstream is the newest renderer. md2rich is one of the oldest. The interesting question for the next year is how many more ends the same Markdown file can be routed to without losing structure, and how many of those renderers stay client-side.