When I started daylog back in 2024, AI wasn’t as smart as it is today. There was no “just ask the model to generate half your editor” shortcut. So I had to do most of the heavy lifting myself. And that’s when I discovered something:
Making a text editor with colors and styles is way harder than it looks.
The naive beginning
daylog is a simple note-taking web app that supports Markdown. At least, that's still the idea.
At the beginning, I thought: “How hard can it be to build a Markdown editor with syntax highlight?” Spoiler #1: very hard (for me at least).
There are basically three ways to approach this:
- Use an existing library.
- Use a plain textarea + preview window.
- Build a fully custom editor that highlights while typing.
I didn’t want to depend on an existing library at first. I wanted control. So I started with option 2: a textarea and a preview panel.
It worked. And actually, it worked really well for my needs.
I took inspiration from the GitHub Issues and PRs editor. Simple textarea. Small toolbar. Preview below. Clean and functional.
But after using my own app for a few months, something bothered me. It felt… cheap. So I wanted more visual feedback. I wanted to instantly see bold text, headings, lists, task items, not just raw Markdown symbols. So I decided to level up.
“I’ll just build my own Markdown editor.”
Yeah. About that...
Problem #1 – The textarea wall
HTML textarea does not support partial styling.
You can change the color of everything.
But you cannot color only bold text or headings.
So I tried hacks.
- Overlay a div on top of the textarea.
- Hide the real content.
- Use contenteditable instead.
This is the moment where things started getting messy.
Problem #2 – The cursor nightmare
Syncing the cursor between a fake highlighted layer and the real textarea is pain.
Selecting text? Broken.
Applying formatting? Misaligned.
Typing fast? Cursor jumps.
With contenteditable, now you’re manually managing selection ranges. Moving the caret. Rebuilding text nodes. Trying not to break everything.
Yes, it’s possible. But maintaining it long-term? That’s a different story.
Problem #3 – Performance reality check
Short notes? Fine.
Large documents with thousands of lines?
Running regex parsing on every keystroke? Not fine.
Input lag started appearing.
And nobody wants to type something and see the result one second later. That’s unacceptable for a writing tool. Sure, “notes” aren’t supposed to be huge. But why limit users?
At some point I had to ask myself: Am I building a note app… or am I building a code editor?
The realization
After a month of struggling, late nights, and too much coffee, I had a moment of clarity: My goal was never to build a text editor engine.
My goal was to build daylog.
So I dropped the “build everything myself” mindset and started searching for a solid Markdown editor. Spoiler #2: that wasn’t easy either.
Monaco: too powerful for its own good
I remembered Monaco, the core editor behind Visual Studio Code. Sounds perfect, right?
Well…
- Easy to integrate at first.
- Extremely heavy for a simple note app.
- Hard to customize with normal CSS.
- Mobile support? Not great.
- Cursor and keyboard behavior on mobile? Painful.
Monaco is amazing. But it was overkill for daylog... So I moved on.
The search
I explored several options:
- CodeMirror – lighter than Monaco, still powerful.
- MDXEditor – powerful but harder to learn.
- react-simple-code-editor – simple, but not actively maintained.
- @uiw/react-md-editor – and this one felt different.
The winner: @uiw/react-md-editor
What I liked about it:
- Easy to implement.
- Configurable.
- Based on textarea encapsulation.
- No heavy code editor engine.
- Supports Mermaid, KaTeX, and GitHub flavored markdown.
- Can be styled with CSS overrides.
It felt aligned with my original idea!.
When I integrated it into daylog and applied some custom CSS tweaks, everything finally clicked.
- The editor looked good.
- It felt responsive.
- It fit the purpose of the app.
And most importantly, I could move forward with the other planned features, and share it here in dev.to ofc!
What I learned
Maybe I gave up too early on building my own editor... Maybe not.
Would it have been a great learning experience? Definitely.
Was it aligned with my product goal? Not really.
Sometimes building everything from scratch is ego.
Sometimes it’s learning.
Sometimes it’s just unnecessary suffering... (in my case).
If you were in my position, what would you have done?
Have you ever gone too deep into building something that wasn’t actually your main product?
I’d love to hear your story.
If you want to see the code, you can check the daylog repository:
https://github.com/artifacts-oss/daylog
Top comments (0)