Why Piskes Slides Draws Shapes Instead of Editing a Slide-as-Document
Piskes Slides is built on a canvas and a shape model, not a document-flow editor pretending to be a deck — here's the actual architectural case for that choice.
Most web-based slide tools, including some of the biggest names in the category, are built the same way underneath: a slide is fundamentally a document, laid out with the same flow-and-reflow logic as a word processor, dressed up to look like a canvas. Piskes Slides isn't built that way. It's a genuine canvas application — built on Konva, a 2D canvas library, with a distinct shape model underneath, not a DOM document wearing a slide's clothing. That's a deliberate architectural choice, and it's worth explaining why, because almost no competing tool actually makes this case out loud.
What "document-as-slide" actually costs you
A document-flow editor is built around the assumption that content reflows — text wraps, elements push each other around, the layout adapts to content changes. That's exactly the right model for a word processor. It's a much worse fit for a slide, where the whole point is that every element sits at a specific position, a specific size, a specific stacking order, and none of that should shift just because a neighboring text box got one line longer. Tools built on a document model for slides are constantly fighting their own foundation to keep layouts from reflowing when they shouldn't — clever constraint systems bolted on top of an architecture that wasn't built for fixed positioning in the first place.
What Piskes Slides is actually built on
Piskes Slides' README describes the slide editor and export as "Konva/PptxGenJS" — a canvas rendering library paired with a PowerPoint-generation library for export. Underneath that, the shape model (frontend/apps/drive/src/lib/slides/shape-model.ts), canvas geometry handling (canvas-geometry.ts), and a deck format (deck-format.ts) all describe the same underlying idea: a slide is a collection of positioned shapes — text boxes, images, drawn elements — each with explicit coordinates, explicit dimensions, and explicit stacking order (z-order), rendered on a canvas rather than laid out by a document engine that has opinions about how content should flow.
What this buys you as the actual user
Precision, mostly. When you place an element on a slide in a true canvas model, it stays exactly where you put it — dragging a text box a few pixels doesn't trigger a cascade of layout recalculation elsewhere on the slide, because there's no flow logic trying to reconcile your placement against some other rule. Z-order — what's in front of what when two elements overlap — is an explicit, direct property you control, not an emergent property of document structure you have to work around. This is the same reason dedicated design tools (Figma, for instance) are built on canvas models rather than document models: fixed, precise, layered composition is what a canvas is actually good at, and it's what a slide fundamentally is.
Why this is worth explaining rather than assuming
Most slide tools don't explain their own architecture this way — Google Slides doesn't publish a technical case for why it's built the way it is, and neither does Canva. That's partly because the underlying choice is invisible to most users most of the time; a canvas-based slide and a document-based slide can look identical in a screenshot. The difference shows up specifically at the edges — precise positioning, layering, behavior when elements overlap — which is exactly where a document-flow model under a slide editor starts to strain against what it's actually being asked to do. Piskes Slides was built on the model that matches what a slide actually is, rather than adapting a model built for something else.