On the editor
Most note-taking software treats them as the same thing. We think that’s the root of why so much of it feels exhausting to use.
Look at the screenshot above. On the left: raw syntax.
# This is something I wanna do,
- [ ] task,
@habit ::daily. Line numbers. A cursor. On the right: the rendered
result — beautiful, structured, readable.
This is a powerful interface for people who understand it. The syntax is the source of truth, and seeing it directly means you can modify anything precisely. For developers and power users, this is ideal.
But for everyone else, it sends a message: this document is made of code. The hashmarks and brackets and double-colons are always visible, always competing with the content. Opening a note means confronting the implementation before you can read the idea. The machinery is never hidden.
Most people, most of the time, are not there to modify the machinery. They wrote something yesterday. They’re back today to remember it. The split view makes that act feel more complicated than it is.
The raw syntax is an instruction set for the renderer — not the content itself. Showing it always is like leaving the assembly instructions on the dining table.
The natural response to the split-editor problem is to go the other direction: make everything visual, hide the syntax entirely, let the formatting render inline as you type. Bear does this. Notion does this. Apple Notes does this. On the surface, it feels friendlier.
But WYSIWYG editors have their own cost. They make every surface permanently hot. Every paragraph, every heading, every checkbox is always ready to be clicked, dragged, deleted. When you hover over a Notion block, drag handles appear. When you click anywhere in Bear, a cursor drops in. The document is always in a state of potential modification.
This creates a persistent background tension. You can’t fully relax into reading something when you’re also aware that a misclick could accidentally move a heading, trigger a slash command, or delete a block. Your brain holds a small portion of its attention in reserve — a defensive crouch against accidental edits. That awareness is invisible, but it’s there.
The irony is that the more sophisticated the editor, the worse this gets. More features mean more affordances. More affordances mean more interface surface area hovering over your content at all times. A richer editing experience produces a noisier reading experience.
Three models, three tradeoffs
Powerful and precise. The syntax is always visible and always editable. Great for power users who think in markup.
Approachable and immediate. Formatting renders as you type. No syntax to learn. This is Bear, Notion, Apple Notes.
The rendered note is the default state. No editing affordances are shown. To write, you enter edit mode deliberately.
Think about how you interact with a physical notebook. You open it, flip to the right page, and read. If you want to change something, you reach for a pen. That act of picking up the pen is small, but it’s intentional. It marks a deliberate shift from one mode to another. The rest of the time, the notebook is settled — it doesn’t invite you to modify it.
Most of the time spent with a note is not the moment of creation. It’s the many subsequent moments of return: reviewing before a meeting, checking what you decided last week, reading through a diagram to understand the structure. The act of writing a note is a small fraction of the total time you spend with it.
Software that treats writing and reading as identical activities optimizes for the minority of interactions at the expense of the majority. Every time you open a note to remember something, you’re being given a full editing environment you didn’t ask for.
The act of writing a note is a small fraction of the total time you spend with it. The rest is reading. Software should reflect that.
The note opens in view mode. The rendered result fills the screen — clean, no editing affordances, no drag handles, no syntax visible. You read. When you want to change something, you enter edit mode. The source becomes visible, the cursor appears, and the full editing environment is available. When you’re done, you return to view mode and the note settles again.
This keeps the split editor available as a power mode — useful when you’re actively building something complex, writing a new diagram, or debugging syntax. But it’s not the default. The default is the rendered result: your idea, fully formed, with nothing else competing for attention.
You open a note. You see the rendered result. No
syntax. No line numbers. No editing affordances. The
task checkboxes are checkboxes, not
- [ ]. The heading is a heading, not a
#. You can read without your brain holding anything
in reserve.
You press E or click to edit. The syntax becomes visible. The cursor appears. Everything is modifiable. The slash command palette is one keypress away. When you close the editor, the note returns to its settled state — no syntax, no noise.
There’s something psychologically significant about a note that looks complete. When the rendering is clean and the syntax is hidden, the note communicates: this is a finished thought. You wrote it. Now it exists. That feeling of settledness matters, especially for the kind of slow, reflective work that note-taking is supposed to support.
A WYSIWYG editor in which everything is always clickable and rearrangeable sends a different message: nothing here is finished. Everything is in progress. The interface keeps the note in a permanent state of becoming. That’s useful when you’re writing. It’s counterproductive when you’re thinking.
The split editor, meanwhile, never lets the machinery recede. The source code is always in view, always reminding you that there’s a layer of implementation beneath the content. For someone who doesn’t think in Mermaid or markdown, it makes the note feel like a technical artifact rather than a human one.
The right design keeps editing powerful, and keeps reading calm. Not by hiding one from the other permanently, but by giving each its own moment — and letting the default be the one you use most.