SpineEditor vs ProseMirror

What ProseMirror does well

• Schema-driven core. Define node types, mark types, and content expressions; the engine enforces them. Custom node types are first-class.
• Decorations. Attach UI to ranges of the document without changing the document itself.
• Tables and collaboration packages. prosemirror-tables and prosemirror-collab are battle-tested official extensions.
• Mature ecosystem. A decade of issues, talks, blog posts, and packages built around it.

What SpineEditor does at the engine layer

• Explicit Plan stage. ProseMirror commands return a transaction directly; the planning is implicit. SpineEditor compiles every Intent into a Plan artifact you can read, log, or reject before any state mutates.
• Determinism contract. The pipeline is fixed: Intent → Plan → Transaction → Apply → Normalize → Commit. Every stage produces named artifacts you can inspect.
• Built-in trace and replay. Every commit emits structured trace data; reconstruct any session deterministically without custom tooling.
• TypeScript-first. The source is TS; types are part of the public contract, not bindings layered on after.

Engine architecture

Code: insert text at the caret

ProseMirror:

import { EditorState, Transaction } from "prosemirror-state";

const tr: Transaction = view.state.tr.insertText("Hello");
view.dispatch(tr);

SpineEditor:

engine.dispatch({
  kind: "typeText",
  text: "Hello",
});

Choose ProseMirror if

• You want the largest ecosystem of community plugins and battle-tested patterns.
• You're comfortable writing schema, commands, and plugins by hand.
• You want full control over every layer of the editor.

Choose SpineEditor if

• You want every edit to produce an inspectable Plan artifact before mutation.
• You need replayable, deterministic editing for testing or audit.
• You want an engine where the pipeline is the contract, end-to-end.
• You want TypeScript types throughout the public surface.