Honest Engineering Transparency
Every word processor on the web is the result of a trade. This page is about the one we made, what it buys you, and where it costs you.
The case against the DOM
The canvas and wasm editors make a fair argument: browsers have no native concept of fixed pagination, footnotes, or objects anchored to text, and font rendering differs across engines. They're right about all of it.
So they take the DOM away. Every pixel is painted by the editor, and the output is identical everywhere.
What that costs
Determinism is bought with everything the browser gives you for free — caret placement, selection, arrow navigation, accessibility — and it has to be rebuilt from scratch.
More to the point, you can't extend a canvas. No embedding your own React components, no styling it like the rest of your product, no plugins that reach into the document. We wanted those more than we wanted identical pixels.
And pixel-perfection was never on offer anyway
The premise assumes there is one correct rendering to match. There isn't. The same docx opens differently in Word for Windows, Word for Mac and Word Online — Microsoft can't reproduce its own layout across its own products. Anyone promising you a byte-faithful visual round-trip is describing a target that doesn't hold still.
Subpixel rounding and font smoothing mean we won't claim identical rendering across every browser either. What we will claim is the guarantee that actually matters when a document leaves your hands.
Our pagination engine decides where pages break — not the browser. It measures every node and every line, and it owns widow/orphan control, page breaks, headers, footers and footnote placement.
PDF export runs on that same engine. We deliberately don't hand the document to the browser's print fragmentation, because that re-flows the layout and moves things your reader already positioned. The PDF is a capture of the paginated document you were editing, not a second attempt at laying it out.
So the promise isn't “identical to Word.” It's that the document your client receives is the document you approved on screen. For anyone sending contracts out the door, that is the guarantee worth having.
The Stesura Edge
One engine paginates the screen and the PDF. Same measurements, same breaks, same result.
Screen = Print
We commit to best effort on docx round-tripping and we keep pushing on it. We do not market “perfect round-tripping,” and that's a deliberate choice rather than a gap we're hoping to close.
We could have mirrored OOXML's every construct in our own marks and nodes purely so a file could make the trip out and back untouched. That buys fidelity at the price of a data model shaped by a file format instead of by the editing experience, and every feature built afterwards pays that tax. Stesura is a standalone editor — much as Google Docs is a standalone editor and doesn't promise you a byte-identical docx either. Import and export exist to get documents in and out, and we take them seriously; they just aren't what the editor is designed around.
| Feature | Import | Export | Notes |
|---|---|---|---|
| Track Changes | Full | Full | Insertions, deletions and author attribution are preserved both ways. |
| Comments | Full | Full | Threads and replies survive in both directions. |
| Legal numbering | Full | Full | Multi-level lists with restarts and overrides. |
| Equation fields | Partial | Partial | MathML round-trips. Legacy EQ fields import read-only. |
| SmartArt / Drawing | None | None | Rendered as static images on import. |
| Macros (VBA) | None | None | Stripped on import. We are an editor, not a runtime. |
Pagination is the expensive part — every node and line has to be measured. We've done a lot of work here and there is more left on the table.
Up to 200 pages
The range we build and test against. Pagination on, no caveats.
200 – 300 pages
Still comfortable. You may notice pagination settling on large structural edits.
300+ pages
Expect some lag with pagination enabled. Splitting into sections or turning pagination off removes it.
You probably don't want to write thousand-page books in an embedded word processor. You can, but pagination will cost you. Everything below 200 pages is what we optimise for, because it's what contracts and filings actually look like.
One render tree
Nodeviews are just components.
Stesura is built on react-prosemirror, so the document renders inside your React tree rather than beside it. A nodeview is an ordinary component — context, state and portals work the way they do everywhere else in your app, and adding one doesn't mount a separate subtree.
The cost
You have to be a React app.
This is not a headless, framework-agnostic core with adapters. Committing to one render tree is what buys the performance above, and it means there is no Vue, Angular or vanilla build — and won't be. If your product isn't React, Stesura isn't for you, and we'd rather say so here than three months into an evaluation.
Structure vs. freedom
ProseMirror is remarkably extensible, and we've kept that: plugins, commands, custom nodes and marks are all yours. What we don't hand over is the schema. Track changes, comments, numbering and pagination all depend on knowing how the document is shaped.
If you want a fully configurable kit where you define every editor primitive yourself, this library is not for you. If you want a word processor you can extend, it is.
Where we drew a hard line
Caveat 01
Decorations at scale
Decorations are the main performance footgun in any large ProseMirror document. Rebuilding a decoration set on every transaction will cost you; keep it in plugin state and map it through instead. The same applies to anything you run across the whole document on every keystroke.
Caveat 02
Custom nodes and layout
Custom nodes and marks are fully supported, but anything that affects layout also has to be understood by the pagination engine — it can only place what it can measure. Nodes that participate in page flow need to declare how they behave at a page boundary, and heavy CSS in a nodeview will show up in measurement cost.
If you need byte-identical Word output or a non-React build, we're the wrong choice and we'd rather you knew now. If you need a genuinely extensible word processor embedded in your product, with pagination your users can trust, let's talk.