C.W.K.
Stream
Lesson 02 of 04 · published

The One Condition for WYSIWYG

~11 min · wysiwyg, tiptap, prosemirror, justification

Level 0Cold Draft
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"WYSIWYG is only justified if the markup must never appear. For a Markdown native, it never has to."

What WYSIWYG Actually Costs

A WYSIWYG editor (Tiptap, ProseMirror, Lexical) is a genuinely powerful thing — but it comes with a specific cost: it replaces the source string with a rich-text document model. Now bold is a schema node, a heading is a node, and the Markdown you started with has to be parsed into the tree on load and serialized out of it on save. You've traded one representation (source) for three: the tree, the rendered view, and the Markdown you import/export.

The One Condition That Justifies It

That trade is worth it under exactly one condition: the markup characters must never be visible. If you're building a word processor for people who should never see a # or a ** — who want to click a Bold button and see bold, full stop — then a rich-text model is correct and the three-representation cost is the price of that experience. That's a real, valid product. It just isn't this one.

Condition: "markup must NEVER appear"  ->  WYSIWYG is justified (rich-text model)
Condition: "markup is meaningful, keep it" ->  source model + Live Preview

# Rekindle's user is in the second row. So the heavier model buys nothing.

A Markdown Native Doesn't Meet That Condition

Dad is a Markdown native. The vault, the essays, the site content, years of Sublime and Obsidian and iA — all source-mode, all markup-visible, by preference. He wants to see the #. For that user, a WYSIWYG model would fight the workflow at every turn: hiding characters he relies on, forcing a parse/serialize round-trip on a file he'd rather edit directly, and complicating every soul feature that wants to read plain source.

So Rekindle takes the lighter road: source is the model, and Live Preview (decorations) gives the rendered look without the rendered model. You see bold as bold on inactive lines and the raw ** on the line you're editing — the readability of WYSIWYG with none of its representational tax. WYSIWYG wasn't rejected because it's bad; it was rejected because its one justifying condition isn't met.

Code

The decision reduces to one condition·text
Condition                              Correct model
-------------------------------------  ----------------------------
"markup must NEVER appear"              WYSIWYG (rich-text tree)
"markup is meaningful, keep it visible" source + Live Preview (decorations)

# Rekindle's user (a Markdown native) is in the second row.
# So the heavier WYSIWYG model would buy nothing and cost three representations.
Three representations (WYSIWYG) vs one (source)·typescript
// WYSIWYG: the source is parsed into a tree on load, edited as a tree,
// and serialized back to Markdown on save. Three forms to keep in sync.
const tree = parseMarkdownToTree(source); // load
edit(tree);                               // the model you actually edit
const markdown = serializeTreeToMarkdown(tree); // save

// Source model: the string you loaded IS the string you edit IS the string
// you save. One form. Live Preview paints the look without a second model.
let doc = source; // load == edit == save

External links

Exercise

For a writing tool you'd build, answer the single question honestly: must the markup characters NEVER be visible to your user? If yes, WYSIWYG earns its cost. If the user is fine seeing (or prefers) the source, you've just saved yourself a rich-text model and two extra representations. Notice how much of the architecture that one answer decides.
Hint
Be honest about who the user is, not who you imagine. A developer, a Markdown blogger, or a vault-keeper usually wants the source. A non-technical memo writer usually wants the markup gone. The user, not the aesthetic, sets the condition.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.