What Stesura is and isn't

What this is and what this isn’t

If you’re reading this, you’re probably looking for a word processor for the web. You’re in the right place. But before we dive in, let’s manage your expectations.

Stesura is a word processor that is built on top of ProseMirror and is designed to be a performant, extensible and feature-rich word processor for the web.

Its rendering and layout don’t use wasm or a canvas. It is a pure web based solution. And with that, come advantages and disadvantages.

What you can expect

Where it makes sense, it behaves the way Word does, because that’s what your users already know. You can do pretty much anything you want with it and make it your own. We’ve built a real pagination engine that is 100% separate from the underlying document model and supports multiple sections with different formats and orientations, widow/orphan controls, page breaks, etc.

For rendering and layout, we’re not using canvas, we’re not using wasm, we’re not using any other technology that would limit extensibility. This editor is purely built on top of ProseMirror and using the react-prosemirror DOM. (A couple of side features do: proofreading hashes text with a small wasm library, and the PDF viewer draws pages with pdf.js on a canvas. The document itself is always plain DOM.) It is therefore accessible, embeddable and extensible. You can style it, modify it, make it your own, embed react components, create your own plugins, programmatically create, assemble and edit documents, etc. You can export to Word (DOCX), PDF, Markdown and JSON.

Pixel-perfection is a fallacy.

We have put a lot of effort in making this editor as universal as possible across browsers and devices, but this is the web. Chrome/Chromium is our reference browser; other browsers are best effort. Firefox and Safari can wrap lines differently, so the same document can break across pages a little differently there. There is a reason Google moved away from a strictly web based editor to using a canvas based editor. They couldn’t guarantee pixel-perfection across all browsers and devices. We’re not Google and we won’t build a canvas editor (besides you’d have a very hard time extending it). Different font rendering engines, sub-pixel rounding, etc. — there will always be some discrepancies. We’re ok with that, and we hope you are too. And don’t expect docx exports to be either, it’s a black box we can’t control, their fonts are proprietary and their pagination logic is not something they share. But if you’re alright trading pixel-perfection for extensibility and an embedded editor, stick around.

Content on web is supposed to be one continuous stream of text.

Pagination was hard. Especially to make performant — it’s a lot of work to get it right because the web isn’t designed to handle pagination. It’s not designed to handle content that can be split into multiple pages. Text flowing in multiple columns on the same page was the one feature I was sure we’d never support. It’s now there, as an experimental feature (experimental.columnSections), and it’s Chromium-only: it relies on CSS column-wrap: wrap (Chromium 145+), which other browsers don’t support yet. As for the rest, I hope you’ll find it in our features list.

You probably don’t want to write thousand-page books.

This editor is performant. We’ve done a lot of work to make it performant, and we’re confident in our performance. We made a lot of optimizations and there are a lot left on the table. We’re not saying you can’t write a thousand pages, but you should expect some lag with pagination turned on. Turn off pagination, or split it into multiple sections and you’ll be fine, but still, why would you want an embeddable word processor for writing thousand-page books?

This isn’t a docx editor for the web.

Don’t expect perfect roundtripping. DOCX import and export are best effort: lossless is a goal, not a guarantee, and legacy Word features (VML, frames, legacy EQ fields and the like) aren’t supported. Editing DOCX files was never why we built Stesura. This was an architectural decision we made early on, but it doesn’t mean we’re not trying our hardest to get things as close as possible. More information here.

Text processors are not built in a day.

This editor is not perfect, and it’s not going to be perfect tomorrow. We’ve tackled the biggest architectural challenges, and are confident in our schema design. So the core shouldn’t change much. However, there are a lot of features we’re still working on, and a lot of features we’re still planning to add. There are a lot of edge cases we need to address and probably a lot more we haven’t thought of yet. But we’re working on it, and we’re committed to making this editor the best it can be.