Editing as a pipeline, not a pile of commands.
SpineEditor runs every edit through explicit stages — Intent → Plan → Transaction — so behavior is deterministic, inspectable, and replayable before it ever reaches the DOM.
Type # then Space
Recorded artifact
intentReceived
User asked for a heading shortcut.
Why a new engine
Most editors hide behavior in commands and plugins.
In most systems, edits are implemented as command chains, plugin hooks, and event handlers. Behavior lives in code paths you can only understand after they run.
SpineEditor makes behavior explicit by running each edit through a structured pipeline you can observe, test, and control before it runs.
Inspect behavior
Every edit produces explicit artifacts before and after commit.
Control behavior
Modify behavior at the intent, plan, or transaction layer instead of patching command chains.
Replay behavior
Reproduce editing sessions deterministically for debugging, testing, and automation.
The pipeline
The key difference is the Plan stage.
Most editors jump from commands to mutation. SpineEditor works out the change first.
Intent becomes Plan before anything executes. That makes edits easier to understand, test, and control.
Intent
Parse
Plan
Design
Txn
Bundle
Apply
Apply
Norm
Repair
Commit
Save
What makes it different
Editing behavior is data, not hidden in code.
A focused set of primitives for building editors whose behavior stays visible and controllable.
Every edit is explicit
Changes move through named stages instead of disappearing into command chains.
Built-in tracing
Each stage emits structured data you can inspect, compare, and replay.
Reversible edits
Undo runs structured steps, not opaque snapshots.
Structured normalization
Named rules enforce document invariants after each change.
Semantic selection model
Selections are part of the semantic model, not derived from the DOM.
Inspect everything
The system is visible end to end, not hidden behind framework internals.
How it compares
The difference is the execution model.
Most editor frameworks expose document structure and extensibility, but not how edits execute. SpineEditor also makes editing behavior itself explicit.
| Capability | SpineEditor | ProseMirror | Tiptap | CKEditor 5 | TinyMCE |
|---|---|---|---|---|---|
| Explicit plan artifact before mutation | ✓ | — | — | — | — |
| Behavior expressed as an explicit pipeline | ✓ | Commands + plugins | Commands + extensions | Commands + converters | Commands + events |
| First-class replay surface | ✓ | Via custom tooling | Via custom tooling | Inspector / devtools | Event-level only |
| Plugin capability boundaries | ✓ | Open plugin hooks | Open extension hooks | Feature/plugin driven | Plugin + event driven |
| DOM is never the source of truth | ✓ | Model + view | ProseMirror view | Model / view split | DOM model |
Sources: prosemirror.net, tiptap.dev, ckeditor.com, tiny.cloud. Corrections welcome via PR.
Build on an editing model you can actually reason about.
Explore the pipeline, inspect how edits work, and build on a system where behavior stays explicit from input to commit.